Open Stack

Hi Eli,

This is exactly what I want. If you guys think this requirement is reasonable, I’d like to commit a design spec so that we could discuss it in details.

Regards,
Gary Duan

From: Eli Qiao [mailto:liyong.qiao at intel.com]
Sent: Wednesday, April 20, 2016 5:08 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes


Kannan,

I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node.

The scenario may like this:
let say 2 flavors:

  *   flavor_secure
  *   flavor_none_secure
For now, flavor-id in baymodel can only be set as one value, Duan Li's requirement is to using flavor-id = [flavor_none_secure, flavor_secure]
and provision one cluster which minion nodes are build from 2 types of flavor, then after cluster(bay ) provision finished , passing lable to
let k8s cluster to chose a minion node to start pod on that specific node.


For now, Magnum doesn't support it yet, I think it good to have it, but the implementation may be differnece per COE since after we
provision bay, the scheduler work are done by k8s/swarm/mesos.

Eli.

On 2016年04月20日 16:36, Kai Qiang Wu wrote:
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 ?


--

Best Regards, Eli Qiao (乔立勇)

Intel OTC China
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160421/1cc46a89/attachment.html>