[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wentao.ma at hpe.com
Fri Apr 29 09:45:59 UTC 2016


Hi Eli,

Copy that, I will consider that. Thanks.

Regards
Mike


Date: Thu, 28 Apr 2016 17:05:44 +0800

From: Eli Qiao <liyong.qiao at intel.com<mailto:liyong.qiao at intel.com>>

To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>

Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to

                provision minion nodes

Message-ID: <5721D268.4040206 at intel.com<mailto:5721D268.4040206 at 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" <wkqwu at cn.ibm.com<mailto:wkqwu at cn.ibm.com>>

>

> To: "OpenStack Development Mailing List \(not for usage questions\)"

>

> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>

>

> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to

>

>                 provision minion nodes

>

> Message-ID: <201604271004.u3RA49v4008575 at d23av04.au.ibm.com<mailto:201604271004.u3RA49v4008575 at 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: wkqwu at cn.ibm.com<mailto:wkqwu at 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.ma at hpe.com<mailto:wentao.ma at hpe.com>>

>

> To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>"

>

> <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.ma at hpe.com]

>

> > Sent: April-26-16 3:01 AM

>

> > To: openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.ma at hpe.com<mailto:wentao.ma at 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 at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>

>

> > Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao.ma at hpe.com<mailto:wentao.ma at 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.porto at gmail.com]

>

> > Sent: Thursday, April 21, 2016 3:49 AM

>

> > To: OpenStack Development Mailing List (not for usage questions)

>

> > <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.lu at huawei.com<mailto:hongbin.lu at huawei.com>>

>

> > wrote:

>

> > >

>

> > >

>

> > >

>

> > >

>

> > > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)

>

> > > [mailto:li-gong.duan at 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-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at 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-

>

> > request at lists.openstack.org?subject:unsubscribe<mailto:request at 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-

>

> > request at lists.openstack.org?subject:unsubscribe<mailto:request at 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-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at 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.ma at hpe.com<mailto:Email_wentao.ma at hpe.com> <mailto:wentao.ma at 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-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at 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.ma at hpe.com<mailto:wentao.ma at hpe.com>

[http://h71028.www7.hp.com/hpe_logo_email_signature/HPE_logo_email_signature.png]<http://www.hpe.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160429/78ebd8aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3737 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160429/78ebd8aa/attachment-0001.png>


More information about the OpenStack-dev mailing list