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.

Sign up for GitHub

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

Jump to bottom

Allow MachinePools without MachinePoolMachines to exist in workload cluster for clusterctl upgrade e2e test #10134

Closed
nojnhuh opened this issue Feb 9, 2024 · 4 comments · Fixed by #10498
Closed

Allow MachinePools without MachinePoolMachines to exist in workload cluster for clusterctl upgrade e2e test #10134

nojnhuh opened this issue Feb 9, 2024 · 4 comments · Fixed by #10498
Assignees
@willie-yao
Labels
area/testing Issues or PRs related to testing kind/bug Categorizes issue or PR as related to a bug. kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@nojnhuh
Copy link
Contributor

nojnhuh commented Feb 9, 2024

What would you like to be added (User Story)?

As an infrastructure provider, I want to leverage CAPI's clusterctl upgrade e2e test to test upgrades of my provider while it is managing MachinePools without MachinePoolMachines.

Detailed Description

While #9892 enables MachinePools in workload clusters for this test, it still assumes that Machines exist to represent the instances. The test should lift its assumption that a Machine exists for each MachinePool replica to enable testing implementations like CAPZ's AzureManagedMachinePool.

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
/area testing
@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. area/testing Issues or PRs related to testing needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Feb 9, 2024
@nojnhuh nojnhuh mentioned this issue Feb 9, 2024
Open
@sbueringer sbueringer added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Feb 12, 2024
@k8s-ci-robot k8s-ci-robot removed the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Feb 12, 2024
@sbueringer sbueringer added the kind/bug Categorizes issue or PR as related to a bug. label Feb 12, 2024
@sbueringer
Copy link
Member

Sounds good!

/triage accepted

@fabriziopandini
Copy link
Member

/priority important-longterm

@k8s-ci-robot k8s-ci-robot added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Apr 11, 2024
@sbueringer
Copy link
Member

Absolutely makes sense, @nojnhuh feel free to open a PR

/triage accepted

@jackfrancis
Copy link
Contributor

/assign @willie-yao

@willie-yao willie-yao mentioned this issue Apr 23, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@willie-yao willie-yao

Labels
area/testing Issues or PRs related to testing kind/bug Categorizes issue or PR as related to a bug. kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Milestone
No milestone
6 participants
@jackfrancis @sbueringer @fabriziopandini @nojnhuh @k8s-ci-robot @willie-yao