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

add deprecation warnings for all cloud providers #69171

Merged
merged 1 commit into from Sep 29, 2018

Conversation

@andrewsykim
Member

andrewsykim commented Sep 27, 2018

What this PR does / why we need it:
Adds a deprecation warning for all cloud providers. Please note that this is only a deprecation warning, there are no expected code changes from doing this. Once all providers have external cloud controllers that are stable and widely used we will fully disable provider functionality, but we don't anticipate that for maybe another year.

Release note:

add deprecation warning for all cloud providers
@andrewsykim

This comment has been minimized.

Show comment
Hide comment
Member

andrewsykim commented Sep 27, 2018

@dims

This comment has been minimized.

Show comment
Hide comment
@dims

dims Sep 27, 2018

Member

/lgtm
/hold

(please feel free to cancel the hold when folks have given their thumbs up Andrew)

Member

dims commented Sep 27, 2018

/lgtm
/hold

(please feel free to cancel the hold when folks have given their thumbs up Andrew)

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Sep 27, 2018

Member

@andrewsykim -- I have a preference towards ...will be removed in a future release over ...will be removed in the near future.

Member

justaugustus commented Sep 27, 2018

@andrewsykim -- I have a preference towards ...will be removed in a future release over ...will be removed in the near future.

@hogepodge

This comment has been minimized.

Show comment
Hide comment
@hogepodge

hogepodge Sep 27, 2018

Member

I recommend the following actions:

  • reaching out to all providers to make sure their deprecation messages are accurate
  • back-porting messages to next stable 1.12 release to capture most accurate information (especially in light of some of the negative feedback we got to 1.12 deprecation warnings).
Member

hogepodge commented Sep 27, 2018

I recommend the following actions:

  • reaching out to all providers to make sure their deprecation messages are accurate
  • back-porting messages to next stable 1.12 release to capture most accurate information (especially in light of some of the negative feedback we got to 1.12 deprecation warnings).
@neolit123

This comment has been minimized.

Show comment
Hide comment
@neolit123

neolit123 Sep 27, 2018

Member

/kind cleanup

Member

neolit123 commented Sep 27, 2018

/kind cleanup

@yastij

This comment has been minimized.

Show comment
Hide comment
@yastij

yastij Sep 27, 2018

Member

Mostly lgtm, we might want to point users to the kep or something that contains our timeline for moving out-of-tree

Member

yastij commented Sep 27, 2018

Mostly lgtm, we might want to point users to the kep or something that contains our timeline for moving out-of-tree

@hogepodge

This comment has been minimized.

Show comment
Hide comment
@hogepodge

hogepodge Sep 28, 2018

Member

Thinking about the message, as a sig are we willing to put a date on earliest removal? "This code is deprecated and may be removed at the 1. release or later" where is sufficiently far enough in the future to give us time to do it properly.

Member

hogepodge commented Sep 28, 2018

Thinking about the message, as a sig are we willing to put a date on earliest removal? "This code is deprecated and may be removed at the 1. release or later" where is sufficiently far enough in the future to give us time to do it properly.

@yastij

This comment has been minimized.

Show comment
Hide comment
@yastij

yastij Sep 28, 2018

Member

If we do have a timeline, we do have to warn users about it.

Member

yastij commented Sep 28, 2018

If we do have a timeline, we do have to warn users about it.

@frapposelli

This comment has been minimized.

Show comment
Hide comment
@frapposelli

frapposelli Sep 28, 2018

Member

Should we consider the Kubernetes deprecation policy for this?

Technically, cloud controller manager is still a beta feature in 1.12, if it graduates to GA in 1.13, following the deprecation policy, we should wait 3 releases or 12 months (whichever is longer) before removing the cloud provider code from k/k.

In the context of this specific PR, I echo @justaugustus comment, we should reword the deprecation note with ...will be removed in a future release, and maybe change the message with the explicit version once the deprecation policy kicks in.

Member

frapposelli commented Sep 28, 2018

Should we consider the Kubernetes deprecation policy for this?

Technically, cloud controller manager is still a beta feature in 1.12, if it graduates to GA in 1.13, following the deprecation policy, we should wait 3 releases or 12 months (whichever is longer) before removing the cloud provider code from k/k.

In the context of this specific PR, I echo @justaugustus comment, we should reword the deprecation note with ...will be removed in a future release, and maybe change the message with the explicit version once the deprecation policy kicks in.

@d-nishi

This comment has been minimized.

Show comment
Hide comment
@d-nishi

d-nishi Sep 28, 2018

a) completely on board with adding the deprecation warning;
b) agree with @frapposelli on adopting deprecation period/policy from kubernetes aka 3 releases (or) 12 months before removing the code from k/k;
c) this might require us to initiate the deprecation warning/period as a governance requirement as soon as the alpha of the out-of-tree ccm is available for majority of the providers.

d-nishi commented Sep 28, 2018

a) completely on board with adding the deprecation warning;
b) agree with @frapposelli on adopting deprecation period/policy from kubernetes aka 3 releases (or) 12 months before removing the code from k/k;
c) this might require us to initiate the deprecation warning/period as a governance requirement as soon as the alpha of the out-of-tree ccm is available for majority of the providers.

@k8s-ci-robot k8s-ci-robot removed the lgtm label Sep 28, 2018

@andrewsykim

This comment has been minimized.

Show comment
Hide comment
@andrewsykim

andrewsykim Sep 28, 2018

Member

Reworded to ...removed in a future release. I agree that it would be nice to put a concrete release where we will remove providers, but we're learning that removing providers from in-tree is really complicated/difficult and don't want to commit to anything here yet until we have a better understanding of the scope. Having said that, if we're all in agreeance to add a release to make a stronger case here (maybe 1.16, 3 releases from 1.13), and adjust as we go, I'm cool with that too. Thoughts?

Member

andrewsykim commented Sep 28, 2018

Reworded to ...removed in a future release. I agree that it would be nice to put a concrete release where we will remove providers, but we're learning that removing providers from in-tree is really complicated/difficult and don't want to commit to anything here yet until we have a better understanding of the scope. Having said that, if we're all in agreeance to add a release to make a stronger case here (maybe 1.16, 3 releases from 1.13), and adjust as we go, I'm cool with that too. Thoughts?

@d-nishi

This comment has been minimized.

Show comment
Hide comment
@d-nishi

d-nishi Sep 28, 2018

assuming alpha is 1.13 for most, 1.16 for final deprecation makes sense with the possibility to extend to 1.17.

d-nishi commented Sep 28, 2018

assuming alpha is 1.13 for most, 1.16 for final deprecation makes sense with the possibility to extend to 1.17.

@andrewsykim

This comment has been minimized.

Show comment
Hide comment
@andrewsykim

andrewsykim Sep 28, 2018

Member

1.16 for final deprecation makes sense with the possibility to extend to 1.17.

Works for me! Any objections?

Member

andrewsykim commented Sep 28, 2018

1.16 for final deprecation makes sense with the possibility to extend to 1.17.

Works for me! Any objections?

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Sep 28, 2018

Member

Not sure I agree. Are we saying that the "deprecation clock" starts with a out-of-tree CP in alpha? I'd imagine that we'd instead start the clock closer to beta or GA phase. The timeline also makes an assumption that it will only take one release cycle to move through to the next phase, which is not strictly true.

That said, I don't think we need to nail down specific timelines until there's a wider discussion with SIG Arch. The language as it exists in this PR is ambiguous enough to suit the current case.

/lgtm
(SIG Azure)

Member

justaugustus commented Sep 28, 2018

Not sure I agree. Are we saying that the "deprecation clock" starts with a out-of-tree CP in alpha? I'd imagine that we'd instead start the clock closer to beta or GA phase. The timeline also makes an assumption that it will only take one release cycle to move through to the next phase, which is not strictly true.

That said, I don't think we need to nail down specific timelines until there's a wider discussion with SIG Arch. The language as it exists in this PR is ambiguous enough to suit the current case.

/lgtm
(SIG Azure)

@k8s-ci-robot

This comment has been minimized.

Show comment
Hide comment
@k8s-ci-robot

k8s-ci-robot Sep 28, 2018

Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewsykim, dims, justaugustus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Contributor

k8s-ci-robot commented Sep 28, 2018

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewsykim, dims, justaugustus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@d-nishi

This comment has been minimized.

Show comment
Hide comment
@d-nishi

d-nishi Sep 28, 2018

@justaugustus -- good point and I agree. we can start the clock post beta in 1.14 or 1.15 and close after 3 releases aka 1.17 or 1.18

d-nishi commented Sep 28, 2018

@justaugustus -- good point and I agree. we can start the clock post beta in 1.14 or 1.15 and close after 3 releases aka 1.17 or 1.18

@cheftako

This comment has been minimized.

Show comment
Hide comment
@cheftako

cheftako Sep 28, 2018

Member

Worth remembering that the deprecation clock is how long we have to wait to be allowed to do the delete, not when we are forced to do the delete. If we start the clock now, we would be allowed to delete in 1.16. However we could still do the delete later than that. So deprecating early is just giving more warning notice to everyone.

Member

cheftako commented Sep 28, 2018

Worth remembering that the deprecation clock is how long we have to wait to be allowed to do the delete, not when we are forced to do the delete. If we start the clock now, we would be allowed to delete in 1.16. However we could still do the delete later than that. So deprecating early is just giving more warning notice to everyone.

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Sep 28, 2018

Member

Agreed that having a wider period is preferable, but I still feel that that clock shouldn't start until beta phase.

Member

justaugustus commented Sep 28, 2018

Agreed that having a wider period is preferable, but I still feel that that clock shouldn't start until beta phase.

@andrewsykim

This comment has been minimized.

Show comment
Hide comment
@andrewsykim

andrewsykim Sep 28, 2018

Member

Okay, but seems like we all agree that having some sort of warning in place sooner is better than later. I will follow up to add that information once we have a better idea. Also important to note, the CCM is in beta currently, we just need more providers adopting in production environments.

Thanks all!

/hold cancel

Member

andrewsykim commented Sep 28, 2018

Okay, but seems like we all agree that having some sort of warning in place sooner is better than later. I will follow up to add that information once we have a better idea. Also important to note, the CCM is in beta currently, we just need more providers adopting in production environments.

Thanks all!

/hold cancel

@k8s-ci-robot k8s-ci-robot merged commit 4b12761 into kubernetes:master Sep 29, 2018

18 checks passed

cla/linuxfoundation andrewsykim authorized
Details
pull-kubernetes-bazel-build Job succeeded.
Details
pull-kubernetes-bazel-test Job succeeded.
Details
pull-kubernetes-cross Skipped
pull-kubernetes-e2e-gce Job succeeded.
Details
pull-kubernetes-e2e-gce-100-performance Job succeeded.
Details
pull-kubernetes-e2e-gce-device-plugin-gpu Job succeeded.
Details
pull-kubernetes-e2e-gke Skipped
pull-kubernetes-e2e-kops-aws Job succeeded.
Details
pull-kubernetes-e2e-kubeadm-gce Skipped
pull-kubernetes-integration Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce-big Job succeeded.
Details
pull-kubernetes-local-e2e Skipped
pull-kubernetes-local-e2e-containerized Skipped
pull-kubernetes-node-e2e Job succeeded.
Details
pull-kubernetes-typecheck Job succeeded.
Details
pull-kubernetes-verify Job succeeded.
Details
tide In merge pool.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment