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.

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

Create a v1alpha2 apiVersion #1526

Closed
vdemeester opened this issue Nov 5, 2019 · 2 comments · Fixed by #2035
Closed

Create a v1alpha2 apiVersion #1526

vdemeester opened this issue Nov 5, 2019 · 2 comments · Fixed by #2035
Assignees
Labels
area/api Indicates an issue or PR that deals with the API. area/release Indicates an issue on release (process, tasks). kind/feature Categorizes issue or PR as related to a new feature.

Comments

@vdemeester
Copy link
Member

As discussed in the working group, let's try to create a v1alpha2 apiVersion for 0.9, where we do our main breaking changes, and use our webhook to do the conversion (see #1379).

What this means:

  1. the controller works with v1alpha2 struct only
  2. the webhook can unmarshall v1alpha1 struct and convert them into v1alpha2 (so that it can be consumed by the controller)

The only question that remains: if I update my current tekton instance, I will have v1alpha1 objects, what should we do with thoses ?

  • Update them one shot (at the start of the controller, somewhere else) ?
  • Ignore them completely ?

/kind feature
/area api
/area release
/assign

@tekton-robot tekton-robot added kind/feature Categorizes issue or PR as related to a new feature. area/api Indicates an issue or PR that deals with the API. area/release Indicates an issue on release (process, tasks). labels Nov 5, 2019
@vdemeester vdemeester added this to the Pipelines 0.9 🐱 milestone Nov 5, 2019
@vdemeester
Copy link
Member Author

Another question rises from that : where should the PipelineResource struct live ?

@bobcatfish
Copy link
Collaborator

There was a bit of context to this (and #1379) that I had to ask many questions of @dlorenc (and @jonjohnsonjr ) before I could understand that I want to share for anyone else who doesn't know, specifically more on 1) why we need to be able to bump the API version and 2) why we need to be able to convert between the versions.

I think the TL;DR is that our beta policy/plan suggests following the kubernetes deprecation policy, which has some details that weren't intuitive to me:

  • The way that CRDs are implemented right now, it's only possible to store one version in etcd, meaning the CRDs have to be completely recreated when the schema changes
  • We want to support painless upgrades but also downgrades, within a moving window of API versions (e.g. you should be able to downgrade from v1beta3 - latest - to v1beta1 without information loss) <-- afaik this doesn't apply to new fields that have been added in v1beta2 or v1beta3

And these have direct benefits: in our current deprecation policy, we assume that users are always aware of what version of Tekton they are using and they are always the ones deciding to upgrade. (Plus we don't support downgrading at all!)

I hadn't thought about what this would mean for folks who are offering services on top of Tekton or managed instances where the user wouldn't be in control of the upgrade (I think @skaegi might have mentioned this but I didn't quite get it). (Once a feature has been deprecated for long enough, the user will still need to make a change so there's still that.)

Anyway probably none of this is news to the people who already understood the problem but I feel like I finally get it :D (And if this explanation is still flawed plz help me refine it!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue or PR that deals with the API. area/release Indicates an issue on release (process, tasks). kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants