Hi KaiQiang, Thank you for your reply.
As for 1), You are correct in that Magnum does support 2 flavors(one is for master node and the other is for minion nodes). What I want to address is whether we should support 2 or N Nova flavors ONLY for minion nodes. As for 2), We have made Magnum templates works with Ironic(only for Fedora/Atomic/Kubernetes) to create a Magnun bay of Kubernetess and uses the flat network for now (as, for now Ironic doesn’t support VLAN network) in our proto environment. Currently we just use Heat template(Resource Group) -> Nova:Server -> Ironic driver as Nova hypervisor to implement it. Regards, Gary From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: Wednesday, April 20, 2016 4:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? Also in this summit https://etherpad.openstack.org/p/magnum-newton-design-summit-topics, we will have session about ironic cases: here it is : Ironic Integration: Add support for Ironic virt-driver If you had ways to make ironic work with Magnum, we welcome your contribution for that topic. Thanks Best Wishes, -------------------------------------------------------------------------------- Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com<mailto:wk...@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! [Inactive hide details for "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---20/04/2016 03:46:18 pm---Hi Folks, We are considerin]"Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---20/04/2016 03:46:18 pm---Hi Folks, We are considering whether Magnum can supports 2 Nova flavors to provision Kubernetes and From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" <li-gong.d...@hpe.com<mailto:li-gong.d...@hpe.com>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: 20/04/2016 03:46 pm 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? Regards, Gary__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
