Open Stack

> -----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