[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
