✨ New CRD + controller for OpenStackServer (v1alpha1)#2067
✨ New CRD + controller for OpenStackServer (v1alpha1)#2067k8s-ci-robot merged 1 commit intokubernetes-sigs:mainfrom
Conversation
✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
721f487 to
8c090fe
Compare
ccbf0b6 to
f081701
Compare
b80f256 to
c608240
Compare
b5c3f50 to
cd77e8a
Compare
18a83a6 to
0354264
Compare
9f8ea24 to
2356928
Compare
| wantRemoveFinalizer bool | ||
| clusterNotReady bool | ||
| }{ | ||
| { |
There was a problem hiding this comment.
I translated all these tests into openstackserver_controller.
There was a problem hiding this comment.
Is there any validation we can't do with CEL? If not, lets delete this.
There was a problem hiding this comment.
the only validation we make here is to ensure immutability. I don't know enough CEL to know if it can check that. However I'll investigate. However I'm not sure if CEL recognize TopologyDryRunAnnotation (link).
I checked other providers and they do that via the webhook.
There was a problem hiding this comment.
Lets put all of these in the apivalidations suite instead. That way they will still work when we implement them with CEL.
There was a problem hiding this comment.
I'll put that into a separate commit for now as I'm not sure whether we want to keep the same validations in OpenStackMachine (?).
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test e2e jobs passed, I want to see if they pass again a few times to ensure I didn't miss any race. |
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
|
Two successful CI jobs in a row. Let's try a third and stop the rechecks, letting others to review. |
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
2 similar comments
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
mdbooth
left a comment
There was a problem hiding this comment.
I've looked through OS Server and OS Machine.
OS Server looks fine except for the unused IPAM field in the spec. I think there are a few things to address in OS Machine.
2 high level things to consider:
- Should OS Server support IPAM?
- Should OS Machine pass fully resolved resources to OS Server?
My personal take on these is:
OS Server should support IPAM. i.e. Leave FloatingIPPoolRef in OS Server spec and add support for it. Remove that support from OS Machine and instead just copy the field from OS Machine spec to OS Server spec.
OS Machine should not fully resolve resources, otherwise we're just duplicating this behaviour between OS Server and OS Machine. i.e. Remove everything from OS Machine that populates or reads resolved or adopted resources.
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
3 similar comments
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
|
Just a (clean) rebase on main. |
|
/test pull-cluster-api-provider-openstack-e2e-full-test pull-cluster-api-provider-openstack-e2e-test |
|
/lgtm Let's do this! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mdbooth 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 |
What this PR does / why we need it:
A new CRD and controller which will manage the OpenStack servers in the cluster.
#2020
#2021
TODOs:
OpenStackServerAPI &&make generateOpenStackClusterannotations and watch for changes in Bastion spec, where any change would trigger abastionDelete.UserDataas a refFuture work that can happen outside this PR:
OpenStackClusterandOpenStackMachineobjects, since they now live inOpenStackServer. The fields will be removed for a potentialv1.SetupWithManagerwhen watching forOpenStackServer, since we are only interested in certain state transition: when the server is deleted, and when the server is ready. For that we probably want to write Predicate functions.