Add proposal for AzureManagedCluster graduation from experimental #2602
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
release-note-none
jackfrancis
added
the
area/managedclusters
|
/test ls |
|
@marosset: The specified target(s) for
The following commands are available to trigger optional jobs:
Use
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test pull-cluster-api-provider-azure-ci-entrypoint |
|
@jackfrancis: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/assign |
jackfrancis
force-pushed
the
AzureManagedCluster-v1-proposal
branch
from
242d355 to
a70c824
Compare
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
There was a problem hiding this comment.
Overall LGTM
I remember it being brought up before that there might be an implicit dependency here on graduating MachinePool out of experimental in CAPI before we can call AzureManagedCluster stable. Should we note in this doc that that's something we have yet to think through?
There was a problem hiding this comment.
Would it make sense for this proposal to be an issue instead? Enhancement proposals are usually defining a new functionality that has associated user stories and implementation details. This is more of a task list/epic for graduating an existing functionality. On the other hand, Integrate Cluster API Proposal Recommendations is something we'd want to have a concrete proposal for, especially when it comes to user-facing API changes.
jackfrancis
force-pushed
the
AzureManagedCluster-v1-proposal
branch
from
a70c824 to
0114d41
Compare
|
@CecileRobertMichon I agree that whatever happens we are going to want to file issues for commited work. Not sure if that can be helped by having a proposal PR that defines things in a markdown in the repo, or if we can simply "publish" the proposal in an issue description. We can discuss in tomorrow's office hours. |
Did we end up discussing/coming to an agreement on this? personally I'm +1 on just keeping track of tasks as issues with a project board to track progress |
|
@CecileRobertMichon time didn't permit yesterday, but yeah I agree that this doc should pair with an "AzureManagedCluster graduation" project board. I think I'd like to keep this doc open as a (IMO) preferable way to document to all AKS + capz stakeholders the agreed upon definition of "graduation". @zmalik @sonasingh46 @mtougeron and others, please add any feedback that better reflects your ideas of desired progress, and share this with your CTOs :) |
jackfrancis
force-pushed
the
AzureManagedCluster-v1-proposal
branch
from
0114d41 to
9600a32
Compare
|
|
||
| ### 2. Integrate Cluster API Proposal Recommendations | ||
|
|
||
| Once the proposal is accepted and merged into the Cluster API project as an endorsed set of provider recommendations, capz can audit the existing "`AzureManagedCluster`" experimental implementation for areas of disagreement with said recommendations. For each discovery of disagreement, there should be a defensible reason to matriculate a divergent capz Managed Kubernetes implementation into a post-experimental definition of "`AzureManagedCluster`", and ideally some form of sign-off from other provider maintainers. Where community consensus cannot be reached, capz should strongly consider evolving the experimental "`AzureManagedCluster`" implementation to meet the Cluster API Managed Kubernetes recommendation as a pre-requisite to graduating from experimental. |
There was a problem hiding this comment.
Regarding the possibility of a successor to the CAPI proposal, would we block CAPZ's non-experimental managed cluster implementation on that?
There was a problem hiding this comment.
No. In fact there is no mention of a "Cluster API-native" ManagedCluster definition in this doc. Once a working group starts making progress towards this (assuming this proposal doc hasn't yet merged), it would probably make sense to mention that effort, and to explicitly state that AzureManagedCluster graduation is not dependent upon that proposal.
Off the top of my head I'd estimate that a long-term, capi ManagedCluster solution would be a v1 thing (graduation of AzureManagedCluster will be within the v1beta1 API scope).
jackfrancis
force-pushed
the
AzureManagedCluster-v1-proposal
branch
from
9600a32 to
092dbb9
Compare
k8s-ci-robot
added
size/L
|
@nojnhuh @CecileRobertMichon @mtougeron I've updated this proposal to reflect recent events, added some status to various items, and have started organizing links to issues that reflect work done. PTAL, I wonder if we can merge this soon and then regularly maintain it if things change. |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
| authors: | ||
| - "@jackfrancis" | ||
| reviewers: | ||
| - @CecileRobertMichon |
There was a problem hiding this comment.
did everyone listed in reviewers actually review? if not let's remove those who didn't prior to merge (or get their review)
There was a problem hiding this comment.
@zmalik @NovemberZulu @mtougeron could you kindly review this and weigh in?
If we don't hear from folks in ~a week or so let's remove those names from this list and finalize for merge.
There was a problem hiding this comment.
I'll take a look by EOD Monday.
|
/lgtm |
|
/lgtm |
| - https://github.com/kubernetes-sigs/cluster-api/issues/7494 | ||
|
|
||
|
|
||
| ### 3. Pathway Towards Full AKS Feature Support (Status: DONE) |
There was a problem hiding this comment.
@nojnhuh @mtougeron @sonasingh46 @zioproto @LochanRn @luthermonson
All of you (and apologies to others I haven't mentioned!) have made significant feature contributions to the AzureManagedCluster API recently. As a result of that effort, does anyone have any concerns that the existing API surface area may be non-durable w/ respect to graduation from experimental?
The plan is to "move the existing API forward", based on the conclusion that we have done sufficient validation to confidently predict that additional feature work can continue to successfully land on this existing API. In other words, we have no reason to believe that we'll have to break the API in order to accommodate future AKS features.
Can folks weigh in on their confidence level of the above? Especially if you feel otherwise!
Thank you 🙏
There was a problem hiding this comment.
One of the more potentially disruptive changes I can think of that we haven't addressed yet is exposing the AKS preview APIs (#2625). Even that seems like something we can enable in a backwards-compatible manner though. Overall, nothing else comes to mind that might threaten the integrity of the API based on where I've been focused recently.
|
Lazy consensus timer starting, and expiring ~mid next week (week of Dec 19). |
|
Let's call the lazy consensus expired and land this officially before the winter break. Thanks everyone for your feedback! /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis 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 |
k8s-ci-robot
added
the
approved
What type of PR is this?
/kind documentation
What this PR does / why we need it:
This PR is a proposal that outlines the set of criteria that must be addressed prior to graduating
AzureManagedClusterout of experimental.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Contributes to #2204
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:
Release note: