cluster-api-provider-azure

cluster-api-provider-azure copied to clipboard

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 AzureManagedCluster out 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:

• [ ] squashed commits
• [ ] includes documentation
• [ ] adds unit tests

Release note:

NONE

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

/test ls

@marosset: The specified target(s) for /test were not found. The following commands are available to trigger required jobs:

• /test pull-cluster-api-provider-azure-build
• /test pull-cluster-api-provider-azure-ci-entrypoint
• /test pull-cluster-api-provider-azure-e2e
• /test pull-cluster-api-provider-azure-test
• /test pull-cluster-api-provider-azure-verify

The following commands are available to trigger optional jobs:

• /test pull-cluster-api-provider-azure-apidiff
• /test pull-cluster-api-provider-azure-apiversion-upgrade
• /test pull-cluster-api-provider-azure-capi-e2e
• /test pull-cluster-api-provider-azure-conformance
• /test pull-cluster-api-provider-azure-conformance-with-ci-artifacts
• /test pull-cluster-api-provider-azure-coverage
• /test pull-cluster-api-provider-azure-e2e-csi-migration
• /test pull-cluster-api-provider-azure-e2e-exp
• /test pull-cluster-api-provider-azure-e2e-optional
• /test pull-cluster-api-provider-azure-e2e-workload-upgrade
• /test pull-cluster-api-provider-azure-windows-containerd-upstream-with-ci-artifacts
• /test pull-cluster-api-provider-azure-windows-containerd-upstream-with-ci-artifacts-serial-slow

Use /test all to run the following jobs that were automatically triggered:

• pull-cluster-api-provider-azure-apidiff
• pull-cluster-api-provider-azure-build
• pull-cluster-api-provider-azure-coverage
• pull-cluster-api-provider-azure-test
• pull-cluster-api-provider-azure-verify

In response to this:

/test ls

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 /test pull-cluster-api-provider-azure-windows-containerd-upstream-with-ci-artifacts /test pull-cluster-api-provider-azure-conformance

@jackfrancis: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-provider-azure-windows-containerd-upstream-with-ci-artifacts	242d35583598e7a9c4e54cc9070dfe75606ed3b4	link	false	/test pull-cluster-api-provider-azure-windows-containerd-upstream-with-ci-artifacts

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

@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.

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 :)

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from jackfrancis by writing /assign @jackfrancis in a comment. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

@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 Thanks for putting this all together!

/lgtm 🚀

/lgtm

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:

• ~~OWNERS~~ [jackfrancis]

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