[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
Tue Apr 26 06:54:37 UTC 2016
Hi Folks
This is mike, I am working with Gary.
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 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
More information about the OpenStack-dev
mailing list