Prow: Use CAPI Operator #917
Conversation
metal3-io-bot
added
the
size/M
|
/hold |
metal3-io-bot
added
the
do-not-merge/hold
|
/cc @adilGhaffarDev @kashifest |
We have so far been relying on imperative commands to manage the lifecycle of CAPI/CAPO and cert-manager. This commit introduces the CAPI Operator with manifests to declaratively manage these components instead. Signed-off-by: Lennart Jern <[email protected]>
lentzi90
force-pushed
the
lentzi90/prow-capi-operator
branch
from
e860251 to
354fbba
Compare
This is a stepping stone to move Prow management to GitOps, not arguing against. 👏 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kashifest 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 |
metal3-io-bot
added
the
approved
| kubectl apply -k capi | ||
| # NOTE! You WILL need to apply multiple times before it is successful. | ||
| # This is because CRDs and webhooks must be in place before other | ||
| # resources can be added. |
There was a problem hiding this comment.
Note this specifically!
This is an opinionated way of working. I put all of it in one kustomization to keep things simple.
However, that kustomization can never be applied in one go. It will always fail the first time you apply, because you cannot create a Certificate or CoreProvider until the CRDs and webhooks are in place.
So the question is, would you rather have a script that does this or is it good like this? Or do you want something different?
To make it crystal clear, the way I would use this if I have to deploy prow from scratch is like this:
- kind create cluster
- kubectl apply -k capi <- This would fail
- Wait a few seconds
- kubectl apply -k capi <- This could potentially succeed but will probably fail
- Wait a few seconds
- kubectl apply -k capi <- This would most likely succeed
- Continue to the next step
There was a problem hiding this comment.
That is not something you do all the time, so documenting it clearly (like above comment) is enough IMO.
|
/override metal3-ubuntu-e2e-integration-test-main |
|
@lentzi90: Overrode contexts on behalf of lentzi90: metal3-ubuntu-e2e-integration-test-main In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
LGTM. it looks great. |
|
/hold cancel |
metal3-io-bot
removed
the
do-not-merge/hold
|
(Changes have been applied) |
We have so far been relying on imperative commands to manage the lifecycle of CAPI/CAPO and cert-manager. This commit introduces the CAPI Operator with manifests to declaratively manage these components instead.
Fixes: #907