🌱 Add design doc for OpenStackServer

[mdbooth]

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

/hold

[netlify[bot]]

✅ 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... Use your smartphone camera to open QR code link.

---

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

[mdbooth]

@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:

• This (obvs)
• External endpoint controllers
• Spine-leaf deployments

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:

• Strictly for 'big' changes only, where 'big' is ill-defined.
• Numeric prefix is the ID of an associated feature request which may just be a stub
• We can and should merge to docs in proposed fairly freely without requiring consensus. This makes change tracking easier, and we can always delete it if we end up not planning to implement it after all.
• Consensus is required to move out of the proposed directory.

Purposes:

• Design review
• Discussion reference for users or external stakeholders (e.g. CAPI/OpenShift)
• Implementation guide
• A roadmap of sorts

[lentzi90]

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]

Awesome proposal :+1:

[EmilienM]

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

[huxcrux]

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

[mdbooth]

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]

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]

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]

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:

[EmilienM]

/hold cancel /approve we can merge the design since the implementation has merged.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: EmilienM

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:

• ~~OWNERS~~ [EmilienM]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[EmilienM]

I'm expediting this but that doesn't mean we can't iterate on the design document that was initially proposed.