Provisions container clusters with multiple Nova flavors
Currently, Magnum can provision a container cluster with one flavor for Master nodes and the other one Nova flavor for slave nodes("minion" nodes in Kubernetes).
There are some requirement on using multiple Nova flavors to provision slave nodes.
Here are one use case:
- There are 2 kind of baremetal machines in customer site: one is legacy machines which doesn’t support UEFI secure boot and others are new machines which support UEFI secure boot. User want to use Magnum to provisions a Magnum bay of Kubernetes from these 2 kind of baremetal machines and for the machines supporting secure boot, user wants to use UEFI secure boot to boot them up. And 2 Kubernetes label(secure-booted and non-secure-booted) are created and User can deploy their data-senstive/
NOTE: As discussed at the team meeting, this blueprint requires a spec to start.
Blueprint information
- Status:
- Not started
- Approver:
- hongbin
- Priority:
- Undefined
- Drafter:
- Ligong Duan
- Direction:
- Approved
- Assignee:
- Ligong Duan
- Definition:
- New
- Series goal:
- None
- Implementation:
- Not started
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
2016-06-03 adrian_otto: Ligong Duan, Why can't this be deployed as two separate bays, each with a different node flavor?
2016-06-12 duanlg: Technically, it is feasible to create 2 separate bays. But using 2 separate bays brings about some inconveniences, including but not limited to, pods located in different bays while serving for one application being difficult to be managed in one place. Another reason is that, we want to provide a technical option, so that user can create a bay using different Nova flavors, instead of having to create different bay due to technical limitations.
Addressed by https:/
Spec of supporting multiple Nova flavor