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

add AKS adoption e2e test and docs #4697

Merged
merged 1 commit into from
Apr 26, 2024

Conversation

nojnhuh
Copy link
Contributor

@nojnhuh nojnhuh commented Apr 1, 2024

What type of PR is this?
/kind feature

What this PR does / why we need it:

This PR tests and documents adopting an existing AKS cluster under management by CAPZ using features that already exist in CAPZ.

Thank you to @mtougeron for blazing this trail!

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1173

Special notes for your reviewer:

  • cherry-pick candidate

TODOs:

  • squashed commits
  • includes documentation
  • adds unit tests

Release note:

Added documentation describing how to adopt an existing AKS cluster.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/feature Categorizes issue or PR as related to a new feature. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Apr 1, 2024
@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Apr 1, 2024
Copy link

codecov bot commented Apr 1, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 62.35%. Comparing base (f71c5ed) to head (a982815).
Report is 9 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4697   +/-   ##
=======================================
  Coverage   62.35%   62.35%           
=======================================
  Files         196      196           
  Lines       16192    16192           
=======================================
  Hits        10097    10097           
  Misses       5362     5362           
  Partials      733      733           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@willie-yao willie-yao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be great to test and document! I left some comments regarding the test, and I'll work on following this doc to see if I can adopt an existing cluster using those steps.

updateResource := []any{"30s", "5s"}

waitForNoBlockMove := func(obj client.Object) {
waitForBlockMoveGone := []any{"30s", "5s"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These values are pretty specific to this test only, so to me it seems like it's fine to keep them local to this file. Otherwise I always feel like I have a hard time tracking down what these values are.

removeFinalizers(cluster)
shouldNotExist(cluster)

clusterctl.ApplyClusterTemplateAndWait(ctx, input.ApplyInput, input.ApplyResult)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused on how this test is laid out. Do we orphan this cluster and then adopt it back as a CAPZ cluster? I'm a bit confused where the adoption occurs since the logic here seems to be only related to orphaning the cluster.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could help to add a code comment to separate the logic between orphaning/adopting the cluster.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we orphan this cluster and then adopt it back as a CAPZ cluster?

Yes, that's how I tried to describe it in the doc comment for this function.

I'm a bit confused where the adoption occurs since the logic here seems to be only related to orphaning the cluster.

The ApplyAndWait at the very end is the adoption. "Adoption" isn't really its own separate thing, it's only applying templates that happen to match existing resources.

@dtzar dtzar added this to the v1.15 milestone Apr 4, 2024
</aside>

CAPZ can adopt some AKS clusters created by other means under its management. This works by crafting CAPI and
CAPZ manifests which describe the existing cluster and creating those resources on the CAPI management
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an example of how this is done? Do we just need to match the metadata of the existing cluster and make sure to add the tag? It could help to give an example of what a manually created CAPZ manifest would look like for a default AKS cluster.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit hesitant to put a full example in the docs if we can't automatically verify it stays correct over time. Definitely could add one anyway, but I'd be interested in getting more user feedback that indicates a full example is worthwhile here before committing to maintaining one.

docs/book/src/topics/managedcluster.md Outdated Show resolved Hide resolved
docs/book/src/topics/managedcluster.md Outdated Show resolved Hide resolved
docs/book/src/topics/managedcluster.md Outdated Show resolved Hide resolved
docs/book/src/topics/managedcluster.md Outdated Show resolved Hide resolved
test/e2e/aks_adopt.go Outdated Show resolved Hide resolved
@nojnhuh
Copy link
Contributor Author

nojnhuh commented Apr 17, 2024

/hold for squash

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 17, 2024
Copy link
Contributor

@willie-yao willie-yao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 25, 2024
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: b3f940811a807b13fc885b023b32d9543d11f6fa

Copy link
Contributor

@mboersma mboersma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mboersma

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

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 25, 2024
@mboersma
Copy link
Contributor

@nojnhuh squash away!

@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 25, 2024
@nojnhuh
Copy link
Contributor Author

nojnhuh commented Apr 25, 2024

squashed!
/hold cancel

Had to rebase to pickup the broken link fix, didn't hit any conflicts though.

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 25, 2024
Copy link
Contributor

@mboersma mboersma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 25, 2024
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 26e56c326d31b3e629cfd8b49d66c61a8ebbdd8f

@k8s-ci-robot k8s-ci-robot merged commit cdf5992 into kubernetes-sigs:main Apr 26, 2024
20 checks passed
@nojnhuh nojnhuh deleted the aks-adopt branch April 26, 2024 00:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Adopt existing AKS clusters
5 participants