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

Decouple CAPM3 from metal3-dev-env #1996

Open
19 tasks
adilGhaffarDev opened this issue Sep 23, 2024 · 5 comments
Open
19 tasks

Decouple CAPM3 from metal3-dev-env #1996

adilGhaffarDev opened this issue Sep 23, 2024 · 5 comments
Labels
triage/accepted Indicates an issue is ready to be actively worked on.

Comments

@adilGhaffarDev
Copy link
Member

adilGhaffarDev commented Sep 23, 2024

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.

    • Define supported versions for BMO and Ironic in test/e2e/config/e2e_conf.yaml. Please check dev-env for right versions
    • Create Kustomize files for BMO and ironic in test/e2e/data folder if they are missing.
    • Launch management minikube cluster, if we want to implement it go check this kind provider. Here is how we are doing it in dev-env
    • Create metal3 namespace
    • Deploy Ironic with Kustomize, example
    • Deploy BMO with Kustomize, example
  • 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.

@metal3-io-bot metal3-io-bot added the needs-triage Indicates an issue lacks a `triage/foo` label and requires one. label Sep 23, 2024
@adilGhaffarDev
Copy link
Member Author

@mquhuy please add tasks related to creating VMs with golang library that we have added in BMO.

@adilGhaffarDev
Copy link
Member Author

cc @Rozzii @kashifest @tuminoid please check

@Rozzii
Copy link
Member

Rozzii commented Sep 25, 2024

/triage accepted

@metal3-io-bot 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 adilGhaffarDev changed the title [wip] Decouple CAPM3 from metal3-dev-env Decouple CAPM3 from metal3-dev-env Oct 30, 2024
@kashifest
Copy link
Member

/cc @lentzi90

@lentzi90
Copy link
Member

lentzi90 commented Dec 5, 2024

Very good! I support this wholeheartedly! 👍
For BMH creation, note that we can skip inspection when it is not needed, by using the status annotation. This is what we do in BMO e2e also

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/accepted Indicates an issue is ready to be actively worked on.
Projects
Status: Backlog
Development

No branches or pull requests

5 participants