<div dir="ltr">Hongbin,<div><br><div>for the implementation of <span style="font-size:14px">heterogeneous, I think we should avoid to talking with nova or other service directly, which will bring lots of coding.</span></div><div><span style="font-size:14px">maybe the best way is to refactor our heat template, and let a bay support several heat template when we scale-out new node or delete additional node.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Eli.</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-02 22:42 GMT+08:00 Hongbin Lu <span dir="ltr"><<a href="mailto:hongbin.lu@huawei.com" target="_blank">hongbin.lu@huawei.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Madhuri,<br>
<br>
It looks both of us agree the idea of having heterogeneous set of nodes. For the implementation, I am open to alternative (I supported the work-around idea because I cannot think of a feasible implementation by purely using Heat, unless Heat support "for" logic which is very unlikely to happen. However, if anyone can think of a pure Heat implementation, I am totally fine with that).<br>
<span class="im HOEnZb"><br>
Best regards,<br>
Hongbin<br>
<br>
> -----Original Message-----<br>
</span><div class="HOEnZb"><div class="h5">> From: Kumari, Madhuri [mailto:<a href="mailto:madhuri.kumari@intel.com">madhuri.kumari@intel.com</a>]<br>
> Sent: June-02-16 12:24 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually<br>
> managing the bay nodes<br>
><br>
> Hi Hongbin,<br>
><br>
> I also liked the idea of having heterogeneous set of nodes but IMO such<br>
> features should not be implemented in Magnum, thus deviating Magnum<br>
> again from its roadmap. Whereas we should leverage Heat(or may be<br>
> Senlin) APIs for the same.<br>
><br>
> I vote +1 for this feature.<br>
><br>
> Regards,<br>
> Madhuri<br>
><br>
> -----Original Message-----<br>
> From: Hongbin Lu [mailto:<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>]<br>
> Sent: Thursday, June 2, 2016 3:33 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually<br>
> managing the bay nodes<br>
><br>
> Personally, I think this is a good idea, since it can address a set of<br>
> similar use cases like below:<br>
> * I want to deploy a k8s cluster to 2 availability zone (in future 2<br>
> regions/clouds).<br>
> * I want to spin up N nodes in AZ1, M nodes in AZ2.<br>
> * I want to scale the number of nodes in specific AZ/region/cloud. For<br>
> example, add/remove K nodes from AZ1 (with AZ2 untouched).<br>
><br>
> The use case above should be very common and universal everywhere. To<br>
> address the use case, Magnum needs to support provisioning<br>
> heterogeneous set of nodes at deploy time and managing them at runtime.<br>
> It looks the proposed idea (manually managing individual nodes or<br>
> individual group of nodes) can address this requirement very well.<br>
> Besides the proposed idea, I cannot think of an alternative solution.<br>
><br>
> Therefore, I vote to support the proposed idea.<br>
><br>
> Best regards,<br>
> Hongbin<br>
><br>
> > -----Original Message-----<br>
> > From: Hongbin Lu<br>
> > Sent: June-01-16 11:44 AM<br>
> > To: OpenStack Development Mailing List (not for usage questions)<br>
> > Subject: RE: [openstack-dev] [magnum] Discuss the idea of manually<br>
> > managing the bay nodes<br>
> ><br>
> > Hi team,<br>
> ><br>
> > A blueprint was created for tracking this idea:<br>
> > <a href="https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay-" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay-</a><br>
> > nodes . I won't approve the BP until there is a team decision on<br>
> > accepting/rejecting the idea.<br>
> ><br>
> > From the discussion in design summit, it looks everyone is OK with<br>
> the<br>
> > idea in general (with some disagreements in the API style). However,<br>
> > from the last team meeting, it looks some people disagree with the<br>
> > idea fundamentally. so I re-raised this ML to re-discuss.<br>
> ><br>
> > If you agree or disagree with the idea of manually managing the Heat<br>
> > stacks (that contains individual bay nodes), please write down your<br>
> > arguments here. Then, we can start debating on that.<br>
> ><br>
> > Best regards,<br>
> > Hongbin<br>
> ><br>
> > > -----Original Message-----<br>
> > > From: Cammann, Tom [mailto:<a href="mailto:tom.cammann@hpe.com">tom.cammann@hpe.com</a>]<br>
> > > Sent: May-16-16 5:28 AM<br>
> > > To: OpenStack Development Mailing List (not for usage questions)<br>
> > > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually<br>
> > > managing the bay nodes<br>
> > ><br>
> > > The discussion at the summit was very positive around this<br>
> > requirement<br>
> > > but as this change will make a large impact to Magnum it will need<br>
> a<br>
> > > spec.<br>
> > ><br>
> > > On the API of things, I was thinking a slightly more generic<br>
> > > approach to incorporate other lifecycle operations into the same<br>
> API.<br>
> > > Eg:<br>
> > > magnum bay-manage <bay> <life-cycle-op><br>
> > ><br>
> > > magnum bay-manage <bay> reset –hard<br>
> > > magnum bay-manage <bay> rebuild<br>
> > > magnum bay-manage <bay> node-delete <name/uuid> magnum bay-manage<br>
> > > <bay> node-add –flavor <flavor> magnum bay-manage <bay> node-reset<br>
> > > <name> magnum bay-manage <bay> node-list<br>
> > ><br>
> > > Tom<br>
> > ><br>
> > > From: Yuanying OTSUKA <<a href="mailto:yuanying@oeilvert.org">yuanying@oeilvert.org</a>><br>
> > > Reply-To: "OpenStack Development Mailing List (not for usage<br>
> > > questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> > > Date: Monday, 16 May 2016 at 01:07<br>
> > > To: "OpenStack Development Mailing List (not for usage questions)"<br>
> > > <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> > > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually<br>
> > > managing the bay nodes<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > I think, user also want to specify the deleting node.<br>
> > > So we should manage “node” individually.<br>
> > ><br>
> > > For example:<br>
> > > $ magnum node-create —bay …<br>
> > > $ magnum node-list —bay<br>
> > > $ magnum node-delete $NODE_UUID<br>
> > ><br>
> > > Anyway, if magnum want to manage a lifecycle of container<br>
> > > infrastructure.<br>
> > > This feature is necessary.<br>
> > ><br>
> > > Thanks<br>
> > > -yuanying<br>
> > ><br>
> > ><br>
> > > 2016年5月16日(月) 7:50 Hongbin Lu<br>
> > > <<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a><mailto:<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>>>:<br>
> > > Hi all,<br>
> > ><br>
> > > This is a continued discussion from the design summit. For recap,<br>
> > > Magnum manages bay nodes by using ResourceGroup from Heat. This<br>
> > > approach works but it is infeasible to manage the heterogeneity<br>
> > across<br>
> > > bay nodes, which is a frequently demanded feature. As an example,<br>
> > > there is a request to provision bay nodes across availability zones<br>
> > [1].<br>
> > > There is another request to provision bay nodes with different set<br>
> > > of flavors [2]. For the request features above, ResourceGroup won’t<br>
> > > work very well.<br>
> > ><br>
> > > The proposal is to remove the usage of ResourceGroup and manually<br>
> > > create Heat stack for each bay nodes. For example, for creating a<br>
> > > cluster with 2 masters and 3 minions, Magnum is going to manage 6<br>
> > Heat<br>
> > > stacks (instead of 1 big Heat stack as right now):<br>
> > > * A kube cluster stack that manages the global resources<br>
> > > * Two kube master stacks that manage the two master nodes<br>
> > > * Three kube minion stacks that manage the three minion nodes<br>
> > ><br>
> > > The proposal might require an additional API endpoint to manage<br>
> > > nodes or a group of nodes. For example:<br>
> > > $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 --<br>
> > > availability-zone us-east-1 ….<br>
> > > $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 --<br>
> > > availability-zone us-east-2 …<br>
> > ><br>
> > > Thoughts?<br>
> > ><br>
> > > [1] <a href="https://blueprints.launchpad.net/magnum/+spec/magnum-" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/magnum/+spec/magnum-</a><br>
> > availability-<br>
> > > zones<br>
> > > [2] <a href="https://blueprints.launchpad.net/magnum/+spec/support-multiple-" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/magnum/+spec/support-multiple-</a><br>
> > > flavor<br>
> > ><br>
> > > Best regards,<br>
> > > Hongbin<br>
> > ><br>
> ><br>
> ______________________________________________________________________<br>
> > > _<br>
> > > ___<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe: OpenStack-dev-<br>
> > > <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><<a href="http://OpenStack-" rel="noreferrer" target="_blank">http://OpenStack-</a><br>
> dev<br>
> > > - <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a>><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > ><br>
> ><br>
> ______________________________________________________________________<br>
> > > _<br>
> > > ___<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe: OpenStack-dev-<br>
> > > <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> _______________________________________________________________________<br>
> ___<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> _______________________________________________________________________<br>
> ___<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">天涯无处不重逢</div>
</div>