Hi Hongbin, Ricardo This is mike, I am working with Gary now. Thanks for Ricardo's good suggestion. I have tried the "map/index" method , we can use it to passed the minion_flavor_map and the index into the minion cluster stack. It does work well. I think we can update magnum baymodel-create to set the N minion flavors in the minion_flavor_map and assign minion counts for each flavor. For example : magnum baymodel-create --name k8s-bay-model --flavor-id minion-flavor-0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types flavor minion node and total minion nodes count is 10. The magnum baymode.py will parse this dictionary and pass them to the heat template parameters minion_flavor_map, minion_flavor_count_map. Then the heat stack will work well.
kubecluster-fedora-ironic.yaml parameters: minion_flavor_map: type: json default: '0': minion-flavor-0 '1': minion-flavor-1 '2': minion-flavor-2 minion_flavor_count_map: type: json default: '0': 3 '1': 5 '2': 2 resources: kube_minions_flavors: type: OS::Heat::ResourceGroup properties: count: { get_param: minion_flavors_counts } resource_def: type: kubecluster-minion-fedora-ironic.yaml properties: minion_flavor_map: {get_param: minion_flavor_map} minion_flavor_count_map: {get_param: minion_flavor_count_map} minion_flavor_index: '%index%' How do you think about this interface in magnum baymodel to support N falvor to provision minion nodes? Do you have any comments about this design for this feature? Thanks && Regards Mike Ma HP Servers Core Platform Software China Email wentao...@hpe.com -----Original Message----- From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) Sent: Monday, April 25, 2016 3:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com> Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Ricardo, This is really good suggestion. I'd like to see whether we can use "foreach"/"repeat" in ResourceGroup in Heat. Regards, Gary Duan -----Original Message----- From: Ricardo Rocha [mailto:rocha.po...@gmail.com] Sent: Thursday, April 21, 2016 3:49 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes 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 __________________________________________________________________________ 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