Hi Hongbin. On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu <hongbin...@huawei.com> wrote: > > > > > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) > [mailto:li-gong.d...@hpe.com] > Sent: April-20-16 3:39 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision > minion nodes > > > > Hi Folks, > > > > We are considering whether Magnum can supports 2 Nova flavors to provision > Kubernetes and other COE minion nodes. > > This requirement comes from the below use cases: > > - 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/cirtical workload/containers/pods on the baremetal machines > which are secure-booted. > > > > This requirement requires Magnum to supports 2 Nova flavors(one is > “extra_spec: secure_boot=True” and the other doesn’t specify it) based on > the Ironic > feature(https://specs.openstack.org/openstack/ironic-specs/specs/kilo-implemented/uefi-secure-boot.html > ). > > > > Could you kindly give me some comments on these requirement or whether it is > reasonable from your point? If you agree, we can write design spec and > implement this feature? > > > > I think the requirement is reasonable, but I would like to solve the problem > in a generic way. In particular, there could be another user who might ask > for N nova flavors to provision COE nodes in the future. A challenge to > support N groups of Nova instances is how to express arbitrary number of > resource groups (with different flavors) in a Heat template (Magnum uses > Heat template to provision COE clusters). Heat doesn’t seem to support the > logic of looping from 1 to N. There could be other challenges/complexities > along the way. If the proposed design can address all the challenges and the > implementation is clean, I am OK to add support for this feature. Thoughts > from others?
This looks similar to the way we looked at passing a list of availability zones. Mathieu asked and got a good answer: http://lists.openstack.org/pipermail/openstack-dev/2016-March/088175.html Something similar can probably be used to pass multiple flavors? Just in case it helps. Cheers, Ricardo > > > > Regards, > > Gary > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev