Has an email been posted to the [heat] community for their input? Maybe I missed it.
Thanks, -Keith On 6/2/16, 9:42 AM, "Hongbin Lu" <[email protected]> wrote: >Madhuri, > >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). > >Best regards, >Hongbin > >> -----Original Message----- >> From: Kumari, Madhuri [mailto:[email protected]] >> Sent: June-02-16 12:24 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually >> managing the bay nodes >> >> Hi Hongbin, >> >> I also liked the idea of having heterogeneous set of nodes but IMO such >> features should not be implemented in Magnum, thus deviating Magnum >> again from its roadmap. Whereas we should leverage Heat(or may be >> Senlin) APIs for the same. >> >> I vote +1 for this feature. >> >> Regards, >> Madhuri >> >> -----Original Message----- >> From: Hongbin Lu [mailto:[email protected]] >> Sent: Thursday, June 2, 2016 3:33 AM >> To: OpenStack Development Mailing List (not for usage questions) >> <[email protected]> >> Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually >> managing the bay nodes >> >> Personally, I think this is a good idea, since it can address a set of >> similar use cases like below: >> * I want to deploy a k8s cluster to 2 availability zone (in future 2 >> regions/clouds). >> * I want to spin up N nodes in AZ1, M nodes in AZ2. >> * I want to scale the number of nodes in specific AZ/region/cloud. For >> example, add/remove K nodes from AZ1 (with AZ2 untouched). >> >> The use case above should be very common and universal everywhere. To >> address the use case, Magnum needs to support provisioning >> heterogeneous set of nodes at deploy time and managing them at runtime. >> It looks the proposed idea (manually managing individual nodes or >> individual group of nodes) can address this requirement very well. >> Besides the proposed idea, I cannot think of an alternative solution. >> >> Therefore, I vote to support the proposed idea. >> >> Best regards, >> Hongbin >> >> > -----Original Message----- >> > From: Hongbin Lu >> > Sent: June-01-16 11:44 AM >> > To: OpenStack Development Mailing List (not for usage questions) >> > Subject: RE: [openstack-dev] [magnum] Discuss the idea of manually >> > managing the bay nodes >> > >> > Hi team, >> > >> > A blueprint was created for tracking this idea: >> > https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay- >> > nodes . I won't approve the BP until there is a team decision on >> > accepting/rejecting the idea. >> > >> > From the discussion in design summit, it looks everyone is OK with >> the >> > idea in general (with some disagreements in the API style). However, >> > from the last team meeting, it looks some people disagree with the >> > idea fundamentally. so I re-raised this ML to re-discuss. >> > >> > If you agree or disagree with the idea of manually managing the Heat >> > stacks (that contains individual bay nodes), please write down your >> > arguments here. Then, we can start debating on that. >> > >> > Best regards, >> > Hongbin >> > >> > > -----Original Message----- >> > > From: Cammann, Tom [mailto:[email protected]] >> > > Sent: May-16-16 5:28 AM >> > > To: OpenStack Development Mailing List (not for usage questions) >> > > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually >> > > managing the bay nodes >> > > >> > > The discussion at the summit was very positive around this >> > requirement >> > > but as this change will make a large impact to Magnum it will need >> a >> > > spec. >> > > >> > > On the API of things, I was thinking a slightly more generic >> > > approach to incorporate other lifecycle operations into the same >> API. >> > > Eg: >> > > magnum bay-manage <bay> <life-cycle-op> >> > > >> > > magnum bay-manage <bay> reset –hard >> > > magnum bay-manage <bay> rebuild >> > > magnum bay-manage <bay> node-delete <name/uuid> magnum bay-manage >> > > <bay> node-add –flavor <flavor> magnum bay-manage <bay> node-reset >> > > <name> magnum bay-manage <bay> node-list >> > > >> > > Tom >> > > >> > > From: Yuanying OTSUKA <[email protected]> >> > > Reply-To: "OpenStack Development Mailing List (not for usage >> > > questions)" <[email protected]> >> > > Date: Monday, 16 May 2016 at 01:07 >> > > To: "OpenStack Development Mailing List (not for usage questions)" >> > > <[email protected]> >> > > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually >> > > managing the bay nodes >> > > >> > > Hi, >> > > >> > > I think, user also want to specify the deleting node. >> > > So we should manage “node” individually. >> > > >> > > For example: >> > > $ magnum node-create —bay … >> > > $ magnum node-list —bay >> > > $ magnum node-delete $NODE_UUID >> > > >> > > Anyway, if magnum want to manage a lifecycle of container >> > > infrastructure. >> > > This feature is necessary. >> > > >> > > Thanks >> > > -yuanying >> > > >> > > >> > > 2016年5月16日(月) 7:50 Hongbin Lu >> > > <[email protected]<mailto:[email protected]>>: >> > > Hi all, >> > > >> > > This is a continued discussion from the design summit. For recap, >> > > Magnum manages bay nodes by using ResourceGroup from Heat. This >> > > approach works but it is infeasible to manage the heterogeneity >> > across >> > > bay nodes, which is a frequently demanded feature. As an example, >> > > there is a request to provision bay nodes across availability zones >> > [1]. >> > > There is another request to provision bay nodes with different set >> > > of flavors [2]. For the request features above, ResourceGroup won’t >> > > work very well. >> > > >> > > The proposal is to remove the usage of ResourceGroup and manually >> > > create Heat stack for each bay nodes. For example, for creating a >> > > cluster with 2 masters and 3 minions, Magnum is going to manage 6 >> > Heat >> > > stacks (instead of 1 big Heat stack as right now): >> > > * A kube cluster stack that manages the global resources >> > > * Two kube master stacks that manage the two master nodes >> > > * Three kube minion stacks that manage the three minion nodes >> > > >> > > The proposal might require an additional API endpoint to manage >> > > nodes or a group of nodes. For example: >> > > $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 -- >> > > availability-zone us-east-1 …. >> > > $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 -- >> > > availability-zone us-east-2 … >> > > >> > > Thoughts? >> > > >> > > [1] https://blueprints.launchpad.net/magnum/+spec/magnum- >> > availability- >> > > zones >> > > [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple- >> > > flavor >> > > >> > > Best regards, >> > > Hongbin >> > > >> > >> ______________________________________________________________________ >> > > _ >> > > ___ >> > > OpenStack Development Mailing List (not for usage questions) >> > > Unsubscribe: OpenStack-dev- >> > > [email protected]?subject:unsubscribe<http://OpenStack- >> dev >> > > - [email protected]?subject:unsubscribe> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > >> ______________________________________________________________________ >> > > _ >> > > ___ >> > > OpenStack Development Mailing List (not for usage questions) >> > > Unsubscribe: OpenStack-dev- >> > > [email protected]?subject:unsubscribe >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> _______________________________________________________________________ >> ___ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev- >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> _______________________________________________________________________ >> ___ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev- >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
