-
Notifications
You must be signed in to change notification settings - Fork 97
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
Decouple CAPM3 from metal3-dev-env #1996
Labels
triage/accepted
Indicates an issue is ready to be actively worked on.
Comments
metal3-io-bot
added
the
needs-triage
Indicates an issue lacks a `triage/foo` label and requires one.
label
Sep 23, 2024
@mquhuy please add tasks related to creating VMs with golang library that we have added in BMO. |
cc @Rozzii @kashifest @tuminoid please check |
/triage accepted |
metal3-io-bot
added
triage/accepted
Indicates an issue is ready to be actively worked on.
and removed
needs-triage
Indicates an issue lacks a `triage/foo` label and requires one.
labels
Sep 25, 2024
adilGhaffarDev
changed the title
[wip] Decouple CAPM3 from metal3-dev-env
Decouple CAPM3 from metal3-dev-env
Oct 30, 2024
/cc @lentzi90 |
Very good! I support this wholeheartedly! 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
User Story
Right now CAPM3 CI is heavily dependent on metal3-dev-env, from environment setup to BMHs creation all is done by metal3-dev-env. We should move it to CAPM3 and also simplify it. Use Kustomize to deploy ironic and BMO instead of cloning repos. Similar work is already done in capm3 clusterctl upgrade tests:
Detailed Description
The following tasks need to be done in order to accomplish this:
(Let's do them in order so it does not break the CI)
Launch management cluster:
NOTE: Right now we are launching minikube cluster for Centos and kind for Ubuntu. In the case of kind cluster we deploy ironic in the container instead of inside the cluster. We should move away from kind and only use Minikube for both Ubuntu and Centos.
Create BMHs
Right now dev-env is creating BMHs in the metal3 namespace which are used by all tests. We should create BMHs at the start of each test and destroy them in the cleanup of each test.
The text was updated successfully, but these errors were encountered: