Skip to content
This repository has been archived by the owner on Jun 8, 2022. It is now read-only.

add podSpecPath into workloadDefinition #240

Merged
merged 1 commit into from
Oct 9, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions apis/core/v1alpha2/core_types.go
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,11 @@ type WorkloadDefinitionSpec struct {
// +optional
RevisionLabel string `json:"revisionLabel,omitempty"`

// PodSpecPath indicates where/if this workload has K8s podSpec field
// if one workload has podSpec, trait can do lot's of assumption such as port, env, volume fields.
// +optional
PodSpecPath string `json:"podSpecPath,omitempty"`

// Extension is used for extension needs by OAM platform builders
// +optional
// +kubebuilder:pruning:PreserveUnknownFields
Expand Down Expand Up @@ -189,9 +194,7 @@ type ComponentParameter struct {
// paths without a leading dot, for example 'spec.replicas'.
FieldPaths []string `json:"fieldPaths"`

// TODO(negz): Use +kubebuilder:default marker to default Required to false
// once we're generating v1 CRDs.

// +kubebuilder:default:=false
// Required specifies whether or not a value for this parameter must be
// supplied when authoring an ApplicationConfiguration.
// +optional
Expand Down Expand Up @@ -231,9 +234,7 @@ type ComponentStatus struct {
// +optional
LatestRevision *Revision `json:"latestRevision,omitempty"`

// TODO(negz): Maintain references to any ApplicationConfigurations that
// reference this component? Doing so would allow us to queue a reconcile
// for consuming ApplicationConfigurations when this Component changed.
// One Component should only be used by one AppConfig
}

// Revision has name and revision number
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,7 @@ spec:
will specify parameter values using this name.
type: string
required:
default: false
description: Required specifies whether or not a value for this
parameter must be supplied when authoring an ApplicationConfiguration.
type: boolean
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,11 @@ spec:
builders
type: object
x-kubernetes-preserve-unknown-fields: true
podSpecPath:
description: PodSpecPath indicates where/if this workload has K8s
podSpec field if one workload has podSpec, trait can do lot's of
assumption such as port, env, volume fields.
type: string
revisionLabel:
description: RevisionLabel indicates which label for underlying resources(e.g.
pods) of this workload can be used by trait to create resource selectors(e.g.
Expand Down
76 changes: 76 additions & 0 deletions design/one-pager-podspecable-workload.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
# Indicate Workload has PodSpec field

- Owner: Jianbo Sun (@wonderflow)
- Date: 10/09/2020
- Status: Implemented

## Background

Since we have added labels like [`workload.oam.dev/podspecable`](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md#labels)
into OAM Spec to indicate the workload will contain 'podSpec' in its spec.

In most famous workload like `Deployment`, `StatefulSet`, `Job`, the `podSpec` field will always be `spec.template.spec`.
But it's hard to know which field is podSpec for K8s CRD. For example, we write a workload named [`PodSpecWorkload`](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/crds/standard.oam.dev_podspecworkloads.yaml).
It has `podSpec` in `spec.podSpec`, this is different with `spec.template.spec`. In this case, we need a field to indicate
which field is `podSpec`.

## Proposal

So I propose we add a field 'podSpecPath' and a label `workload.oam.dev/podspecable: true` into WorkloadDefinition.

The 'podSpecPath' field and the label are both optional fields, they could have following behaviors:

### No label and No `podSpecPath` field

```
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
name: webservice
spec:
definitionRef:
name: podspecworkloads.standard.oam.dev
...
```

In this case, we can't do any podSpec assumption for this workload.

### label specified with No `podSpecPath` field

```
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
name: webservice
labels:
workload.oam.dev/podspecable: true
spec:
definitionRef:
name: podspecworkloads.standard.oam.dev
...
```

In this case, we will always regard `spec.template.spec` as the `podSpecPath`.
This will work for most famous workloads like K8s `Deployment`/`StatefulSet`/`Job` and many other CRD Objects like
`OpenKruise CloneSet`/`Knative Service`.

### Has `podSpecPath` field

```
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
name: webservice
labels:
workload.oam.dev/podspecable: true
spec:
podSpecPath: "spec.podSpec"
definitionRef:
name: podspecworkloads.standard.oam.dev
...
```

If the `podSpecPath` is specified, the `workload.oam.dev/podspecable: true` label will always be automatically added.

In this case, trait can use `podSpecPath` to get the field of podSpec.