[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Kai Qiang Wu
wkqwu at cn.ibm.com
Wed Apr 27 09:38:32 UTC 2016
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, 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/quickstart.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
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>
To: "openstack-dev at lists.openstack.org"
<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 ¨Cnode-count
parameter in baymodel.
So I think it doesn¡¯t need specify minion-flavor-0 counts by ¨Cnode-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
> 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
>
> -----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>
> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <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>
> 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>
> 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
> > 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
> 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
> 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
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/20160427/6bdfb4fe/attachment.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/20160427/6bdfb4fe/attachment.gif>
More information about the OpenStack-dev
mailing list
