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

Update API version to v1 for knative serving #620

Closed
rhuss opened this issue Jan 21, 2020 · 2 comments
Closed

Update API version to v1 for knative serving #620

rhuss opened this issue Jan 21, 2020 · 2 comments
Assignees
Labels
kind/feature New feature or request
Milestone

Comments

@rhuss
Copy link
Contributor

rhuss commented Jan 21, 2020

As v1alpha1 gets removed v0.12.0

v1alpha1 will be only removed in Knative serving v0.13.0 as according to the Knative Release Principles the last 4 Kn releases need to be supported. So for v0.12.0 this means backwards support until v0.9.0. v0.9.0 is the last version which does not yet have support for thev1 API.

For the client I suggest the following process, to be in compliance with the Knative Release Principles:

  • For 0.12.0 we stick to v1alpha1 so that kn works with any cluster down to serving v0.9.0
  • For 0.13.0 we move to v1 endpoints and objects. This implies:
    • switch to v1 objects in our KnServingClient interface
    • update all code to use v1 instead of v1alpha
    • remove the dependency on v1alpha1 (this would be the case anyway as v1alpha1 is removed in serving 0.13)
    • we do not deal with different api versions in the client (like described in Proposal: kn API version support #462 )
    • we do not any fancy version detection (like finding out the storage version of the knative installation at hand) but just use v1 straight away.

So the update becomes straight-forward. The consequences are:

  • kn 0.13 won't work with any Knative serving installation <= 0.9.0
  • For Knative serving installations <= 0.9.0, the user needs to use kn 0.12 or older.

I think this change is reasonably simple but still in conformance with the release principles and straight forward.

IMPORTANT: Don't make the move before v0.12.0 is released.

//cc: @sixolet @navidshaikh @maximilien @dgerd @evankanderson

@rhuss rhuss added the kind/feature New feature or request label Jan 21, 2020
@rhuss rhuss self-assigned this Jan 21, 2020
@rhuss rhuss modified the milestones: v0.12.0, v0.13.0 Jan 21, 2020
@rhuss
Copy link
Contributor Author

rhuss commented Jan 23, 2020

I added some comments at https://docs.google.com/document/d/1GXDe6163lO8ohtLUMPCplbjm3OTpYo_4U8f9K1fgZPo/edit?disco=AAAAI45Sxt8 to clarify how and which versions to support from a kn POV.

The only question is, whether we should just drop CronJobSource when moving to 0.13 (instead of keeping it as described in #619). As Eventing is still v1alpha1 we should be able to do this without to much stress. See for https://docs.google.com/document/d/1GXDe6163lO8ohtLUMPCplbjm3OTpYo_4U8f9K1fgZPo/edit?disco=AAAAI45SxuA for my comment on that.

We should discuss this in one of our next WG calls, maybe the over next one as the next one I can't join. Or let's discuss this offline.

cc: @sixolet

@rhuss
Copy link
Contributor Author

rhuss commented Feb 7, 2020

#640 added support for serving v1. The eventing update is tracked in #609, so let's close this issue here.

@rhuss rhuss closed this as completed Feb 7, 2020
coryrc pushed a commit to coryrc/client that referenced this issue May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant