> -----Original Message----- > From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com] > Sent: April-26-16 3:01 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to > provision minion nodes > > 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
The suggested approach seems to break the existing behaviour. I think it is better to support this feature in a backward-compatible way. How about using labels: $ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0 --node-count 3 --labels extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2 > 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 __________________________________________________________________________ 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