[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Ricardo Rocha
rocha.porto at gmail.com
Wed Apr 20 19:48:37 UTC 2016
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
>
More information about the OpenStack-dev
mailing list