Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Expose v1beta1 to the world ⛈ #2035

Merged
merged 4 commits into from
Mar 2, 2020
Merged

Expose v1beta1 to the world ⛈ #2035

merged 4 commits into from
Mar 2, 2020

Commits on Mar 2, 2020

  1. Expose v1alpha2 through the webhook ⛈ 

    Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
    @vdemeester
    vdemeester committed Mar 2, 2020
    Configuration menu
    Copy the full SHA
    e8e04c8 View commit details
    Browse the repository at this point in the history

  2. Make reconcilers work with the auto-converted struct ⛈ 

    With this commit, the reconcilers (PipelineRun and TaskRun) now uses
the v1alpha2 part of the struct instead of the old one. In a gist,
this means

- `TaskRun.Inputs.Params` becomes `TaskRun.Params`
- `TaskRun.Inputs.Resources` becomes `TaskRun.Resources.Inputs`
- `TaskRun.Outputs.Resources` becomes `TaskRun.Resources.Outputs`

Kubernetes can only store one version of the CRD, and before 1.17
does not support conversion webhook per-se. *Note* that once we have
conversion webhook it will be simpler ; support for conversion webhook
should land soon-ish in knative.dev/pkg which will allow us to easily
switch to it.

> 1. Pick a conversion strategy. Since custom resource objects need to
> be able to be served at both versions, that means they will
> sometimes be served at a different version than their storage
> version. In order for this to be possible, the custom resource
> objects must sometimes be converted between the version they are
> stored at and the version they are served at. If the conversion
> involves schema changes and requires custom logic, a conversion
> webhook should be used. If there are no schema changes, the default
> None conversion strategy may be used and only the apiVersion field
> will be modified when serving different versions.
> 2. If using conversion webhooks, create and deploy the conversion
> webhook. See the Webhook conversion for more details.

As written above, we can only store one version on the CRD and we want
to serve multilple. To keep the latest API the cleanest (here
`v1alpha2`), we are using `v1alpha1` and making sure that `v1alpha1`
struct are compatible (aka a `v1alpha2` struct can be serialized in a
`v1alpha1` struct so that it can be stored). This is what the
auto-conversion role is :

- take a version and convert it to the most recent version (here
  `v1alpha2`)
- then store it as the lowest version (here `v1alpha1`)

For the controller this means we still work with `v1alpha1`
struct *but* with only the part that is compatible with
`v1alpha2`.

One follow-up will be to rename the `v1alpha1` field that are not used
anymore, prepending them with `Deprecated`.

Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
    @vdemeester
    vdemeester committed Mar 2, 2020
    Configuration menu
    Copy the full SHA
    900dfd2 View commit details
    Browse the repository at this point in the history

  3. Add v1alpha2 yaml tests 🐺 

    - move current examples in `examples/v1alpha1`
- copy and migrate those examples for `v1alpha1` (in `examples/v1alpha2`)

Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
    @vdemeester
    vdemeester committed Mar 2, 2020
    Configuration menu
    Copy the full SHA
    5b60eb8 View commit details
    Browse the repository at this point in the history

  4. Rename v1alpha2 to v1beta1 😌 

    Let's go directly to v1beta1 and do several RC releases 👼

Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
    @vdemeester
    vdemeester committed Mar 2, 2020
    Configuration menu
    Copy the full SHA
    7cf986d View commit details
    Browse the repository at this point in the history