Hi Eli, Copy that, I will consider that. Thanks.
Regards Mike Date: Thu, 28 Apr 2016 17:05:44 +0800 From: Eli Qiao <liyong.q...@intel.com<mailto:liyong.q...@intel.com>> To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Message-ID: <5721d268.4040...@intel.com<mailto:5721d268.4040...@intel.com>> Content-Type: text/plain; charset="utf-8"; Format="flowed" hi Mike Can you please also consider the effect to do rebuild/resize a bay if you want to support more than 1 nova flavor? There are some discussion while in Austin summit, check https://etherpad.openstack.org/p/newton-magnum-bays-lifecycle-operations Thanks Eli. On 2016?04?28? 16:52, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wrote: > > Hi Kai Qiang, > > Thanks for your comments, your consideration is very comprehensive, I > think it is a good way to implement this feature. > > Regards > > Mike > > Date: Wed, 27 Apr 2016 17:38:32 +0800 > > From: "Kai Qiang Wu" <wk...@cn.ibm.com<mailto:wk...@cn.ibm.com>> > > To: "OpenStack Development Mailing List \(not for usage questions\)" > > <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> > > Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to > > provision minion nodes > > Message-ID: > <201604271004.u3ra49v4008...@d23av04.au.ibm.com<mailto:201604271004.u3ra49v4008...@d23av04.au.ibm.com>> > > Content-Type: text/plain; charset="gb2312" > > Hi Mike, > > Since right now, we have also support bay-update (node_count) > > I am thinking the following case: > > 1> baymodel-create have default flavor, and extra labels specify > the(other > > node flavors) requirements, > > if (other node flavors) count <= bay(node_count), the extra nodes > would be > > created use default flavor > > if (other node flavors) count > bay(node_count), it should pop error, > > since it not quite clear why flavor to use > > 2> magnum bay-update k8sbay replace node_count < existed node_count, > 2> it > > should be OK. same as old behavior > > if node_count > existed node_count, all new nodes would use > default > > flavor_id, (if not, we need to find what's the better policy to handle > > that) > > Refer: > > https://github.com/openstack/magnum/blob/master/doc/source/dev/quickst > art.rst > > What do you think ? > > Thanks > > Best Wishes, > > ---------------------------------------------------------------------- > ---------- > > Kai Qiang Wu (??? Kennan? > > IBM China System and Technology Lab, Beijing > > E-mail: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com> > > Tel: 86-10-82451647 > > Address: Building 28(Ring Building), ZhongGuanCun Software Park, > > No.8 Dong Bei Wang West Road, Haidian District Beijing > P.R.China > > 100193 > > ---------------------------------------------------------------------- > ---------- > > Follow your heart. You are miracle! > > From: "Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" > <wentao...@hpe.com<mailto:wentao...@hpe.com>> > > To: > "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" > > <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> > > Date: 27/04/2016 03:10 pm > > Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 > Nova flavor to > > provision minion nodes > > Hi Hong bin, > > Thanks very much. It?s good suggestion, I think it is a good way by > using > > labels for extra flavors. But I notice that there is not the > ?node-count > > parameter in baymodel. > > So I think it doesn?t need specify minion-flavor-0 counts by ?node-count. > > We can specify all of the flavor id and count ratio in the labels. It > will > > check the minion node count with this ratio of labels when creating > magnum > > bay that specified total minion node count . If the node-count in > baycreate > > doesn?t match with the flavor ratio, it will return the ratio match > error > > message. If there is not the multi-flavor-ratio key in lables, it will > > just use minion-flavor-0 to create 10 minion nodes. > > $ magnum baymodel-create --name k8sbaymodel --flavor-id > minion-flavor-0 > > --labels multi- > > flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2 > > $ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count > 10 > > Do you think about it? > > > -----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<mailto: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<mailto: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<mailto:openstack-dev@lists.openstack.org>> > > > Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) > > <wentao...@hpe.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > <http://lists.openstack.org/pipermail/openstack-dev/attachments/201604 > 27/6bdfb4fe/attachment-0001.html> > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: graycol.gif > > Type: image/gif > > Size: 105 bytes > > Desc: not available > > URL: > <http://lists.openstack.org/pipermail/openstack-dev/attachments/201604 > 27/6bdfb4fe/attachment-0001.gif> > > ------------------------------ > > Mike Ma > > HP Servers Core Platform Software China > > Mobile +86 18610248322 > > email_wentao...@hpe.com<mailto:email_wentao...@hpe.com> > <mailto:wentao...@hpe.com>_ > > http://h71028.www7.hp.com/hpe_logo_email_signature/HPE_logo_email_sign > ature.png > <http://www.hpe.com/> > > > > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Best Regards, Eli Qiao (???) > Intel OTC China -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160428/8b6c13a4/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3737 bytes Desc: not available URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160428/8b6c13a4/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: liyong_qiao.vcf Type: text/x-vcard Size: 123 bytes Desc: not available URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160428/8b6c13a4/attachment-0001.vcf> ------------------------------ Mike Ma HP Servers Core Platform Software China Mobile +86 18610248322 Email wentao...@hpe.com<mailto:wentao...@hpe.com> [http://h71028.www7.hp.com/hpe_logo_email_signature/HPE_logo_email_signature.png]<http://www.hpe.com/>
__________________________________________________________________________ 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
