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

Applying BMH Should Be Part of the Test Setup #1383

Open
mboukhalfa opened this issue Apr 12, 2024 · 3 comments
Open

Applying BMH Should Be Part of the Test Setup #1383

mboukhalfa opened this issue Apr 12, 2024 · 3 comments
Labels
triage/accepted Indicates an issue is ready to be actively worked on.

Comments

@mboukhalfa
Copy link
Member

mboukhalfa commented Apr 12, 2024

Currently, in the Metal³ dev-env, BMHs are applied in the metal3 namespace and then inspected during the make process. However, when reusing CAPI tests such as md_remediations.go, which utilizes random namespace we are applying bmh in that namespace through the hook PostNamespaceCreated, it becomes evident that applying BMHs in the metal3 namespace and then deleting them in e2e tests, only to recreate them in a different namespace, is not the most efficient approach.

To streamline the testing process and ensure alignment with evolving testing methodologies, it's recommended to update dev-env so that BMHs are applied as part of the test setup, directly in the appropriate namespace, rather than being applied by default in the metal3 namespace as part of the make process.

Proposed Solution:

  1. Remove the step of applying BMHs in the verify.sh script and inspecting them.
  2. Update the Ansible tests under /tests to apply the BMHs from a separate file before running the tests.
  3. Eliminate the part where BMHs are deleted from the metal3 namespace and instead include applying them as part of every e2e test.
  4. Remove the BMH file bmhosts_crs.yaml since it will no longer be needed (#1353)

Reference: metal3-io/cluster-api-provider-metal3#1080

@metal3-io-bot metal3-io-bot added the needs-triage Indicates an issue lacks a `triage/foo` label and requires one. label Apr 12, 2024
@Rozzii
Copy link
Member

Rozzii commented Apr 24, 2024

/triage accepted
I am willing to accept it but please whoever fixes this make it so that the BMHs can be deployed without running the tests and deploying CPI and CAPM3, this would be a big help for those who are developing only BMO functionality without higher level Metal3 components.

@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 Apr 24, 2024
@metal3-io-bot
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@metal3-io-bot metal3-io-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 23, 2024
@Rozzii
Copy link
Member

Rozzii commented Jul 24, 2024

/remove-lifecycle stale

@metal3-io-bot metal3-io-bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 24, 2024
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

3 participants