CORS-3139: Move CAPI behind infrastructure provider interface#7824
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
openshift-merge-robot
added
the
needs-rebase
|
/test e2e-openstack-ovn |
|
/test e2e-openstack-ovn openstack-manifests |
|
/test whyareyouignoringme |
|
@pierreprinetti: The specified target(s) for
The following commands are available to trigger optional jobs:
Use
DetailsIn 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/test-infra repository. |
|
uh. So if our tests are skipped because of a regexp in openshift/release, then it is not possible to trigger them manually? |
patrickdillon
force-pushed
the
infra-interface-assets
branch
from
a88ea87 to
2949dde
Compare
openshift-merge-robot
removed
the
needs-rebase
patrickdillon
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
vincepri
left a comment
vincepri
left a comment
There was a problem hiding this comment.
small nits, other than that lgtm
|
/retitle CORS-3139: Move CAPI behind infrastructure provider interface |
openshift-ci
bot
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@patrickdillon: This pull request references CORS-3139 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. DetailsIn 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 openshift-eng/jira-lifecycle-plugin repository. |
patrickdillon
force-pushed
the
infra-interface-assets
branch
from
2949dde to
440ce68
Compare
We could temporarily disable the linter for that whole file and solve the linting issues in a follow-up PR. TBH I think what you're doing is fine, since we don't get many opportunities to work on tech debt. |
|
Polished, rebased and squashed the WIP from yesterday. Still need to do some final testing. |
|
We noticed that the PreTerraform hook is executed in the CAPI flow. Is that expected? In that hook we run different infra preparation steps compared to what we do pre CAPI. |
patrickdillon
force-pushed
the
infra-interface-assets
branch
from
c279158 to
68ee163
Compare
openshift-merge-robot
added
the
needs-rebase
Moves tfvars to its own package to decouple it from the cluster asset.
After moving tfvars.go to its own package, the linter is kicking up a lot of dust.
Updates the infrastructure provider interface to accept Parent assets-- rather than a list of files. This allows for easier handling of assets by the infrastructure provider.
Moves LoadMetadata to a separate package to allow implementers of the infrastructure provider interface to utilize the function. The cluster asset/package does not use LoadMetadata but does depend on the implementers of the interface. Moving to a separate package breaks the dependency loop.
Move the path for capi manifests to capiutils and export it. This will allow the use of the same constant when breaking CAPI machine manifests into a separate asset.
Creates an independent asset for CAPI machines, rather than being a part of the cluster API manifests asset. This separation will make it easier to apply the CAPI machines in a second stage, after the CAPI infrastructure assets.
patrickdillon
force-pushed
the
infra-interface-assets
branch
from
68ee163 to
462d8b7
Compare
openshift-merge-robot
removed
the
needs-rebase
Let's discuss/handle in a separate PR. |
Implements the infrastructure provider interface with the CAPI system. This encapsulates the CAPI implementation similar to Terraform. It also maintains pkg/infrastructure/platform.go (and build variants) as the canonical source of truth for choosing an infrastructure provider. This also adds an interface that cloud platforms utilizing the CAPI provisioning should implement to provision additional resources.
patrickdillon
force-pushed
the
infra-interface-assets
branch
2 times, most recently
from
ff0cc60 to
3cb0c98
Compare
Implements basic logic for handling bootstrap destroy through the CAPI infra provider. Further bootstrap destroy logic, including platform-specific implementations, may be needed to ensure proper destruction of all bootstrap resources.
patrickdillon
force-pushed
the
infra-interface-assets
branch
from
3cb0c98 to
a03afe9
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: patrickdillon, vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
@patrickdillon: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
[ART PR BUILD NOTIFIER] This PR has been included in build ose-installer-altinfra-container-v4.16.0-202401300919.p0.gba9211c.assembly.stream for distgit ose-installer-altinfra. |
11 participants
This PR:
Moving the CAPI implementation behind the infrastructure provider platform encapsulates CAPI implementation details. It also allows pkg/infrastructure/platform to be the canonical source of truth of which infrastructure provider a cloud platform is using.
The
CAPIInfraHelperinterface provides a simple implementation for cloud platforms to interact with the CAPI provisioning pattern. This is intended to be a baseline interface that can be build upon and extended. It is not intended to be complete, but intends to be flexible enough to allow handling needs that will arise across multiple cloud platforms.