Open mdbooth opened 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.
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.
@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:
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.proposed
directory.Purposes:
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:
Awesome proposal :+1:
/lgtm we can iterate later on the design but I think overall it's a solid start.
I'm a bit late to the party however think the proposal sounds good :+1: /lgtm
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
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.
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?
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:
Design proposal for https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/2020
/hold