kubernetes-sigs / cluster-api-provider-openstack

Cluster API implementation for OpenStack
https://cluster-api-openstack.sigs.k8s.io/
Apache License 2.0
275 stars 253 forks source link

🌱 Add design doc for OpenStackServer #2021

Open mdbooth opened 2 months ago

mdbooth commented 2 months ago

Design proposal for https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/2020

/hold

k8s-ci-robot commented 2 months ago

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from mdbooth. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
netlify[bot] commented 2 months ago

Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name Link
Latest commit 9b05e94563118c508e2226d577f8bbbaa77d008a
Latest deploy log https://app.netlify.com/sites/kubernetes-sigs-cluster-api-openstack/deploys/661fc31e4cf1760008165153
Deploy Preview https://deploy-preview-2021--kubernetes-sigs-cluster-api-openstack.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

mdbooth commented 2 months ago

@lentzi90 Meta point: I recall you doing something similar before, but I can't find it to re-use it. I'm thinking of writing 2-4 of these in fairly quick succession, so it might be an opportunity to try to make something stick. If we have a better process already I'll switch to that instead.

Hoping to write them for:

The latter likely has tentacles and may turn in to more than one (e.g. separate doc for failure domains).

My thoughts on this are:

Purposes:

lentzi90 commented 2 months ago

The previous thing I did is not merged so that's probably why you didn't find it :smile: For that I used date-based naming because I just copied what CAPI does. They also have a template if you want to steal it. I have no strong opinion on this though. :smile:

EmilienM commented 2 months ago

Awesome proposal :+1:

EmilienM commented 2 months ago

/lgtm we can iterate later on the design but I think overall it's a solid start.

huxcrux commented 2 months ago

I'm a bit late to the party however think the proposal sounds good :+1: /lgtm

mdbooth commented 2 months ago

I'm going to move this around to conform to the pattern set by https://github.com/kubernetes-sigs/cluster-api-provider-openstack/pull/1565

lentzi90 commented 1 month ago

Do we want to include a paragraph or two about if/how this could be used for MachinePool support in CAPO? From my understanding we would "just" need to add one higher level "pool" object to handle OpenStackServers in order to achieve that.

mdbooth commented 1 month ago

Do we want to include a paragraph or two about if/how this could be used for MachinePool support in CAPO? From my understanding we would "just" need to add one higher level "pool" object to handle OpenStackServers in order to achieve that.

What would this look like? I think MachinePool is for when the cloud has some efficiently-implemented native concept of a scalable set of machines. I don't think we have that in OpenStack?

lentzi90 commented 1 month ago

Do we want to include a paragraph or two about if/how this could be used for MachinePool support in CAPO? From my understanding we would "just" need to add one higher level "pool" object to handle OpenStackServers in order to achieve that.

What would this look like? I think MachinePool is for when the cloud has some efficiently-implemented native concept of a scalable set of machines. I don't think we have that in OpenStack?

Good point. I think it would be doable, but we would end up with all the logic in CAPO to manage the pool, which is not ideal. Forget that I mentioned it :sweat_smile: