-
Notifications
You must be signed in to change notification settings - Fork 253
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
✨ Add OpenStackServerGroup CRD and Controller #1912
base: main
Are you sure you want to change the base?
Conversation
Implements new CRD for OpenstackServerGroup in v1alpha8 to allow managed Server Groups with standard policies, and adds ServerGroupRef to OpenstackMachine that references the new CRD and uses it for VM creation. Closes: kubernetes-sigs#1256
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dalees The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @dalees. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
PR needs rebase. 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good, some remarks inline.
// The name of the cloud to use from the clouds secret | ||
// +optional | ||
CloudName string `json:"cloudName"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit weird, we should probably have a reference to an OpenStackCluster instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the feedback! Yeah, this allows the resource to be reconciled alone, as it's self contained.
However that isn't in any of the use cases, it doesn't seem a limitation to be tied to an existing OpenStackCluster even if the OpenStackServerGroup was only used for workers. It would remove duplication of these creds.
I'll make this change, once the CRD approach is agreed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, okay, that's a fair point. The use case to keep all the workers from different clusters in a single ServerGroup makes sense, I see your point.
type ServerGroupRef struct { | ||
// Name of the OpenStackServerGroup resource to be used. | ||
// Must be in the same namespace as the resource(s) being provisioned. | ||
Name string `json:"name"` | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think LocalObjectReference should be used as a type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be an issue that it specifies omitempty
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, it probably would. Okay, the design of this field is good, we can change internals if we want to later.
err = compute.ResolveReferencedMachineResources(scope, &openStackMachine.Spec, &openStackMachine.Status.ReferencedResources) | ||
if err != nil { | ||
return reconcile.Result{}, err | ||
} | ||
|
||
// Resolve referenced resources CAPO resources, using the K8s client | ||
err = resolveReferencedClientResources(ctx, r.Client, openStackMachine) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels like it's still a Machine resource. Couldn't we put that into ResolveReferencedMachineResources
directly? Even if we need to change the arguments of the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I did start by doing this; I changed to this separation as what they're fetching from is distinct (OpenStack resource vs Kubernetes resource) and the client objects used are different. The OpenStack compute package just doesn't feel like the right place to be looking up K8s resources. It also makes test cases clearer to mock each function.
However, I agree the naming isn't clear. I wonder if renaming ResolveReferencedMachineResources
to ResolveReferencedOpenStackResources
may help to this end.
I'm open to changing this, but wanted to provide my reasoning first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that, sure. Let's see what other reviewers will say here, especially @mdbooth as ResolveReferencedMachineResources()
is an idea of his.
func (r *OpenStackServerGroupReconciler) Reconcile(ctx context.Context, req ctrl.Request) (result ctrl.Result, reterr error) { | ||
log := ctrl.LoggerFrom(ctx) | ||
|
||
// Fetch the OpenStackMachine instance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This log seems wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I'll fix this in the next iteration.
// Get the servergroup by name, even if our K8s resource already has the ID field set. | ||
// TODO(dalees): If this returns a 404 do we try to delete with existing UUID? Do we just assume success? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should look up by ID and only then fallback to looking up by name. IDs are safe in case of duplicate names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, happy to change this - I can see it will lead to less problems if a duplicate named resource was created after this managed one.
|
||
serverGroupName := openStackServerGroup.Name | ||
|
||
serverGroup, err := computeService.GetServerGroupByName(serverGroupName, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, we should probably lookup by ID first in case we have duplicate names.
err = compute.ResolveReferencedMachineResources(scope, &openStackMachine.Spec, &openStackMachine.Status.ReferencedResources) | ||
if err != nil { | ||
return reconcile.Result{}, err | ||
} | ||
|
||
// Resolve referenced resources CAPO resources, using the K8s client | ||
err = resolveReferencedClientResources(ctx, r.Client, openStackMachine) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I did start by doing this; I changed to this separation as what they're fetching from is distinct (OpenStack resource vs Kubernetes resource) and the client objects used are different. The OpenStack compute package just doesn't feel like the right place to be looking up K8s resources. It also makes test cases clearer to mock each function.
However, I agree the naming isn't clear. I wonder if renaming ResolveReferencedMachineResources
to ResolveReferencedOpenStackResources
may help to this end.
I'm open to changing this, but wanted to provide my reasoning first.
@@ -22,8 +22,8 @@ import ( | |||
) | |||
|
|||
// ResolveReferencedMachineResources is responsible for populating ReferencedMachineResources with IDs of | |||
// the resources referenced in the OpenStackMachineSpec by querying the OpenStack APIs. It'll return error | |||
// if resources cannot be found or their filters are ambiguous. | |||
// the resources referenced in the OpenStackMachineSpec by querying the OpenStack APIs and K8s resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment change will be removed, this package should probably not look up K8s resources.
func (r *OpenStackServerGroupReconciler) Reconcile(ctx context.Context, req ctrl.Request) (result ctrl.Result, reterr error) { | ||
log := ctrl.LoggerFrom(ctx) | ||
|
||
// Fetch the OpenStackMachine instance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I'll fix this in the next iteration.
type ServerGroupRef struct { | ||
// Name of the OpenStackServerGroup resource to be used. | ||
// Must be in the same namespace as the resource(s) being provisioned. | ||
Name string `json:"name"` | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be an issue that it specifies omitempty
?
/ok-to-test |
@pierreprinetti We agreed this in principal this week. Pinging you because it's similar to something ORC would do. |
Hi, at @SovereignCloudStack we are very interested in this feature. What is the progress here @dalees? |
Hello - pleased to hear of the interest! I'm keen to get this in, and I'm scheduled to revisit this in the next few weeks to get it back into a reviewable state. |
What this PR does / why we need it:
Implements new CRD for OpenstackServerGroup in v1alpha8 to allow managed Server Groups with standard policies, and adds ServerGroupRef to OpenstackMachine that references the new CRD and uses it for VM creation.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1256
Special notes for your reviewer:
This implements comment #1256 (comment)
There are a few TODO's remaining in code comments, and documentation of the feature to do. This first version is to ensure we have general agreement on the approach before continuing work on this.
TODOs:
/hold