Open Stack

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?

Regards,
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160420/0f237a9e/attachment.html>