Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
Thanks for getting the forum setup. I have added some high-level autoscaling use case to the etherpad that will help during the discussion. Duc (dtruong) On Wed, Oct 24, 2018 at 2:10 AM Rico Lin wrote: > Hi all, I'm glad to notify you all that our forum session has been > accepted [1] and that forum time schedule (Thursday, November 15, > 9:50am-10:30am) should be stable by now. So please save your schedule for > it!! > Any feedback are welcome! > > > > [1] > https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22753/autoscaling-integration-improvement-and-feedback > > On Tue, Oct 9, 2018 at 3:07 PM Rico Lin wrote: > >> a reminder for all, please put your ideas/thoughts/suggest actions in our >> etherpad [1], >> which we gonna use for further discussion in Forum, or in PTG if we got >> no forum for it. >> So we won't be missing anything. >> >> >> >> [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback >> >> On Tue, Oct 9, 2018 at 2:22 PM Qiming Teng wrote: >> >>> > >One approach would be to switch the underlying Heat AutoScalingGroup >>> > >implementation to use Senlin and then deprecate the AutoScalingGroup >>> > >resource type in favor of the Senlin resource type over several >>> > >cycles. >>> > >>> > The hard part (or one hard part, at least) of that is migrating the >>> existing >>> > data. >>> >>> Agreed. In an ideal world, we can transparently transplant the "scaling >>> group" resource implementation onto something (e.g. a library or an >>> interface). This sounds like an option for both teams to brainstorm >>> together. >>> >>> - Qiming >>> >>> >>> >>> __ >>> 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 >>> >> >> >> -- >> May The Force of OpenStack Be With You, >> >> *Rico Lin*irc: ricolin >> >> > > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > > __ > 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 > __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
Hi all, I'm glad to notify you all that our forum session has been accepted [1] and that forum time schedule (Thursday, November 15, 9:50am-10:30am) should be stable by now. So please save your schedule for it!! Any feedback are welcome! [1] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22753/autoscaling-integration-improvement-and-feedback On Tue, Oct 9, 2018 at 3:07 PM Rico Lin wrote: > a reminder for all, please put your ideas/thoughts/suggest actions in our > etherpad [1], > which we gonna use for further discussion in Forum, or in PTG if we got no > forum for it. > So we won't be missing anything. > > > > [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback > > On Tue, Oct 9, 2018 at 2:22 PM Qiming Teng wrote: > >> > >One approach would be to switch the underlying Heat AutoScalingGroup >> > >implementation to use Senlin and then deprecate the AutoScalingGroup >> > >resource type in favor of the Senlin resource type over several >> > >cycles. >> > >> > The hard part (or one hard part, at least) of that is migrating the >> existing >> > data. >> >> Agreed. In an ideal world, we can transparently transplant the "scaling >> group" resource implementation onto something (e.g. a library or an >> interface). This sounds like an option for both teams to brainstorm >> together. >> >> - Qiming >> >> >> __ >> 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 >> > > > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
a reminder for all, please put your ideas/thoughts/suggest actions in our etherpad [1], which we gonna use for further discussion in Forum, or in PTG if we got no forum for it. So we won't be missing anything. [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback On Tue, Oct 9, 2018 at 2:22 PM Qiming Teng wrote: > > >One approach would be to switch the underlying Heat AutoScalingGroup > > >implementation to use Senlin and then deprecate the AutoScalingGroup > > >resource type in favor of the Senlin resource type over several > > >cycles. > > > > The hard part (or one hard part, at least) of that is migrating the > existing > > data. > > Agreed. In an ideal world, we can transparently transplant the "scaling > group" resource implementation onto something (e.g. a library or an > interface). This sounds like an option for both teams to brainstorm > together. > > - Qiming > > > __ > 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 > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
> >One approach would be to switch the underlying Heat AutoScalingGroup > >implementation to use Senlin and then deprecate the AutoScalingGroup > >resource type in favor of the Senlin resource type over several > >cycles. > > The hard part (or one hard part, at least) of that is migrating the existing > data. Agreed. In an ideal world, we can transparently transplant the "scaling group" resource implementation onto something (e.g. a library or an interface). This sounds like an option for both teams to brainstorm together. - Qiming __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
On Thu, Sep 27, 2018 at 11:45 PM Zane Bitter wrote: > On 26/09/18 10:27 PM, Qiming Teng wrote: > > Heat still has a *lot* of users running very important stuff on Heat > scaling group code which, as you know, is burdened by a lot of technical > debt. > > Though I agree that a common library that can be used by both projects would be really good, I still don't understand what user issues (though the resource implementations are not the best, they actually work) we're trying to address here. As far as duplicated effort is concerned (that's the only justification I could get from the etherpad), possibly senlin duplicated some stuff expecting to replace heat implementation in time. Also, we've not made any feature additions to heat group resources since long time (expecting senlin to do it instead) and I've not seen any major bugs reported by users. May be we're talking about duplicated effort in the "future", now that we have changed plans for heat ASG?;) >> What will be great if we can build common library cross projects, and use > >> that common library in both projects, make sure we have all improvement > >> implemented in that library, finally to use Senlin from that from that > >> library call in Heat autoscaling group. And in long-term, we gonna let > all > > > > +1 - to expand on Rico's example, we have at least 3 completely separate > implementations of batching, each supporting different actions: > > Heat AutoscalingGroup: updates only > Heat ResourceGroup: create or update > Senlin Batch Policy: updates only > > and users are asking for batch delete as well. > I've seen this request a few times. But, what I wonder is "why a user would want to do a delete in a controlled batched manner"? The only justifications provided is that "they want to throttle requests to other services, as those services are not able to handle large concurrent requests sent by heat properly". Are we not looking at the wrong place to fix those issues? IMHO, a good list of user issues on the mentioned etherpad would really help justify the effort needed. This is clearly an area > where technical debt from duplicate implementations is making it hard to > deliver value to users. > > cheers, > Zane. > > __ > 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 > -- Regards, Rabi Mishra __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
On 27/09/18 7:00 PM, Duc Truong wrote: On Thu, Sep 27, 2018 at 11:14 AM Zane Bitter wrote: and we will gradually fade out the existing 'AutoScalingGroup' and related resource types in Heat. That's almost impossible to do without breaking existing users. One approach would be to switch the underlying Heat AutoScalingGroup implementation to use Senlin and then deprecate the AutoScalingGroup resource type in favor of the Senlin resource type over several cycles. The hard part (or one hard part, at least) of that is migrating the existing data. Not saying that this is the definitive solution, but it is worth discussing as an option since this follows a path other projects have taken (e.g. nova-volume extraction into cinder). +1, *definitely* worth discussing. A prerequisite to this approach would probably require Heat to create the so-called common library to house the autoscaling code. Then Senlin would need to achieve feature parity against this autoscaling library before the switch could happen. Clearly there are _some_ parts that could in principle be shared. (I added some comments to the etherpad to clarify what I think Rico was referring to.) It seems to me that there's value in discussing it together rather than just working completely independently, even if the outcome of that discussion is that +1. The outcome of any discussion will be beneficial not only to the teams but also the operators and users. Regards, Duc (dtruong) __ 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 __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
On Thu, Sep 27, 2018 at 11:14 AM Zane Bitter wrote: > > > and we will gradually fade out the existing 'AutoScalingGroup' > > and related resource types in Heat. > > That's almost impossible to do without breaking existing users. One approach would be to switch the underlying Heat AutoScalingGroup implementation to use Senlin and then deprecate the AutoScalingGroup resource type in favor of the Senlin resource type over several cycles. Not saying that this is the definitive solution, but it is worth discussing as an option since this follows a path other projects have taken (e.g. nova-volume extraction into cinder). A prerequisite to this approach would probably require Heat to create the so-called common library to house the autoscaling code. Then Senlin would need to achieve feature parity against this autoscaling library before the switch could happen. > > Clearly there are _some_ parts that could in principle be shared. (I > added some comments to the etherpad to clarify what I think Rico was > referring to.) > > It seems to me that there's value in discussing it together rather than > just working completely independently, even if the outcome of that > discussion is that +1. The outcome of any discussion will be beneficial not only to the teams but also the operators and users. Regards, Duc (dtruong) __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
On 26/09/18 10:27 PM, Qiming Teng wrote: Hi, Due to many reasons, I cannot join you on this event, but I do like to leave some comments here for references. On Tue, Sep 18, 2018 at 11:27:29AM +0800, Rico Lin wrote: *TL;DR* *How about a forum in Berlin for discussing autoscaling integration (as a long-term goal) in OpenStack?* First of all, there is nothing called "auto-scaling" in my mind and "auto" is most of the time a scary word to users. It means the service or tool is hiding some details from the users when it is doing something without human intervention. There are cases where this can be useful, there are also many other cases the service or tool is messing up things to a state difficult to recover from. What matters most is the usage scenarios we support. I don't think users care that much how project teams are organized. Yeah, I mostly agree with you, and in fact I often use the term 'scaling group' to encompass all of the different types of groups in Heat. Our job is to provide an API that is legible to external tools to increase and decrease the size of the group. The 'auto' part is created by connecting it with other services, whether they be OpenStack services like Aodh or Monasca, monitoring services provided by the user themselves, or just manual invocation. (BTW people from the HA-clustering world have a _very_ negative reaction to Senlin's use of the term 'cluster'... there is no perfect terminology.) Hi all, as we start to discuss how can we join develop from Heat and Senlin as we originally planned when we decided to fork Senlin from Heat long time ago. IMO the biggest issues we got now are we got users using autoscaling in both services, appears there is a lot of duplicated effort, and some great enhancement didn't exist in another service. As a long-term goal (from the beginning), we should try to join development to sync functionality, and move users to use Senlin for autoscaling. So we should start to review this goal, or at least we should try to discuss how can we help users without break or enforce anything. The original plan, iirc, was to make sure Senlin resources are supported in Heat, This happened. and we will gradually fade out the existing 'AutoScalingGroup' and related resource types in Heat. That's almost impossible to do without breaking existing users. I have no clue since when Heat is interested in "auto-scaling" again. It's something that Rico and I have been discussing - it turns out that Heat still has a *lot* of users running very important stuff on Heat scaling group code which, as you know, is burdened by a lot of technical debt. What will be great if we can build common library cross projects, and use that common library in both projects, make sure we have all improvement implemented in that library, finally to use Senlin from that from that library call in Heat autoscaling group. And in long-term, we gonna let all user use more general way instead of multiple ways but generate huge confusing for users. The so called "auto-scaling" is always a solution, built by orchestrating many moving parts across the infrastructure. In some cases, you may have to install agents into VMs for workload metering. Totally agree, but... I am not convinced this can be done using a library approach. Clearly there are _some_ parts that could in principle be shared. (I added some comments to the etherpad to clarify what I think Rico was referring to.) It seems to me that there's value in discussing it together rather than just working completely independently, even if the outcome of that discussion is that *As an action, I propose we have a forum in Berlin and sync up all effort from both teams to plan for idea scenario design. The forum submission [1] ended at 9/26.* Also would benefit from both teams to start to think about how they can modulize those functionalities for easier integration in the future. From some Heat PTG sessions, we keep bring out ideas on how can we improve current solutions for Autoscaling. We should start to talk about will it make sense if we combine all group resources into one, and inherit from it for other resources (ideally gonna deprecate rest resource types). Like we can do Batch create/delete in Resource Group, but not in ASG. We definitely got some unsynchronized works inner Heat, and cross Heat and Senlin. Totally agree with you on this. We should strive to minimize the technologies users have to master when they have a need. +1 - to expand on Rico's example, we have at least 3 completely separate implementations of batching, each supporting different actions: Heat AutoscalingGroup: updates only Heat ResourceGroup: create or update Senlin Batch Policy: updates only and users are asking for batch delete as well. This is clearly an area where technical debt from duplicate implementations is making it hard to deliver value to users. cheers, Zane.
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
Hi, Due to many reasons, I cannot join you on this event, but I do like to leave some comments here for references. On Tue, Sep 18, 2018 at 11:27:29AM +0800, Rico Lin wrote: > *TL;DR* > *How about a forum in Berlin for discussing autoscaling integration (as a > long-term goal) in OpenStack?* First of all, there is nothing called "auto-scaling" in my mind and "auto" is most of the time a scary word to users. It means the service or tool is hiding some details from the users when it is doing something without human intervention. There are cases where this can be useful, there are also many other cases the service or tool is messing up things to a state difficult to recover from. What matters most is the usage scenarios we support. I don't think users care that much how project teams are organized. > Hi all, as we start to discuss how can we join develop from Heat and Senlin > as we originally planned when we decided to fork Senlin from Heat long time > ago. > > IMO the biggest issues we got now are we got users using autoscaling in > both services, appears there is a lot of duplicated effort, and some great > enhancement didn't exist in another service. > As a long-term goal (from the beginning), we should try to join development > to sync functionality, and move users to use Senlin for autoscaling. So we > should start to review this goal, or at least we should try to discuss how > can we help users without break or enforce anything. The original plan, iirc, was to make sure Senlin resources are supported in Heat, and we will gradually fade out the existing 'AutoScalingGroup' and related resource types in Heat. I have no clue since when Heat is interested in "auto-scaling" again. > What will be great if we can build common library cross projects, and use > that common library in both projects, make sure we have all improvement > implemented in that library, finally to use Senlin from that from that > library call in Heat autoscaling group. And in long-term, we gonna let all > user use more general way instead of multiple ways but generate huge > confusing for users. The so called "auto-scaling" is always a solution, built by orchestrating many moving parts across the infrastructure. In some cases, you may have to install agents into VMs for workload metering. I am not convinced this can be done using a library approach. > *As an action, I propose we have a forum in Berlin and sync up all effort > from both teams to plan for idea scenario design. The forum submission [1] > ended at 9/26.* > Also would benefit from both teams to start to think about how they can > modulize those functionalities for easier integration in the future. > > From some Heat PTG sessions, we keep bring out ideas on how can we improve > current solutions for Autoscaling. We should start to talk about will it > make sense if we combine all group resources into one, and inherit from it > for other resources (ideally gonna deprecate rest resource types). Like we > can do Batch create/delete in Resource Group, but not in ASG. We definitely > got some unsynchronized works inner Heat, and cross Heat and Senlin. Totally agree with you on this. We should strive to minimize the technologies users have to master when they have a need. > Please let me know who is interesting in this idea, so we can work together > and reach our goal step by step. > Also please provide though if you got any concerns about this proposal. > > [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > __ > 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 __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
Thanks for creating the etherpad. I have added a question on the common library in the etherpad. I think we can iterate on the basic proposal before the forum in Berlin so that we can get input from developers who won't be able to attend in person. On Tue, Sep 18, 2018 at 11:46 AM Rico Lin wrote: > cool Duc, and it's nicely started: > https://etherpad.openstack.org/p/autoscaling-integration-and-feedback > I also submit the etherpad, will add you as moderator once it's selected > (don't know why, but can't add any more now from the web). > > Please add whatever you like to that etherpad, I will try to input more > information ASAP. > all information will continue to be used with or without that forum. > > On Wed, Sep 19, 2018 at 12:51 AM Duc Truong > wrote: > >> Hi Rico, >> >> I'm the Senlin PTL and would be happy to have a forum discussion in >> Berlin about the future of autoscaling. >> >> Can you go ahead and start an etherpad to capture the proposed agenda >> and discussion items? Also, feel free to submit the forum submission >> so that we can get it on the schedule. >> >> Thanks, >> >> Duc (dtruong) >> >> On Mon, Sep 17, 2018 at 8:28 PM Rico Lin >> wrote: >> >>> *TL;DR* >>> *How about a forum in Berlin for discussing autoscaling integration (as >>> a long-term goal) in OpenStack?* >>> >>> >>> Hi all, as we start to discuss how can we join develop from Heat and >>> Senlin as we originally planned when we decided to fork Senlin from Heat >>> long time ago. >>> >>> IMO the biggest issues we got now are we got users using autoscaling in >>> both services, appears there is a lot of duplicated effort, and some great >>> enhancement didn't exist in another service. >>> As a long-term goal (from the beginning), we should try to join >>> development to sync functionality, and move users to use Senlin for >>> autoscaling. So we should start to review this goal, or at least we should >>> try to discuss how can we help users without break or enforce anything. >>> >>> What will be great if we can build common library cross projects, and >>> use that common library in both projects, make sure we have all improvement >>> implemented in that library, finally to use Senlin from that from that >>> library call in Heat autoscaling group. And in long-term, we gonna let all >>> user use more general way instead of multiple ways but generate huge >>> confusing for users. >>> >>> *As an action, I propose we have a forum in Berlin and sync up all >>> effort from both teams to plan for idea scenario design. The forum >>> submission [1] ended at 9/26.* >>> Also would benefit from both teams to start to think about how they can >>> modulize those functionalities for easier integration in the future. >>> >>> From some Heat PTG sessions, we keep bring out ideas on how can we >>> improve current solutions for Autoscaling. We should start to talk about >>> will it make sense if we combine all group resources into one, and inherit >>> from it for other resources (ideally gonna deprecate rest resource types). >>> Like we can do Batch create/delete in Resource Group, but not in ASG. We >>> definitely got some unsynchronized works inner Heat, and cross Heat and >>> Senlin. >>> >>> Please let me know who is interesting in this idea, so we can work >>> together and reach our goal step by step. >>> Also please provide though if you got any concerns about this proposal. >>> >>> [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations >>> -- >>> May The Force of OpenStack Be With You, >>> >>> *Rico Lin*irc: ricolin >>> >>> >>> __ >>> 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 >>> >> __ >> 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 >> > > > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > > __ > 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 > __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
cool Duc, and it's nicely started: https://etherpad.openstack.org/p/autoscaling-integration-and-feedback I also submit the etherpad, will add you as moderator once it's selected (don't know why, but can't add any more now from the web). Please add whatever you like to that etherpad, I will try to input more information ASAP. all information will continue to be used with or without that forum. On Wed, Sep 19, 2018 at 12:51 AM Duc Truong wrote: > Hi Rico, > > I'm the Senlin PTL and would be happy to have a forum discussion in > Berlin about the future of autoscaling. > > Can you go ahead and start an etherpad to capture the proposed agenda > and discussion items? Also, feel free to submit the forum submission > so that we can get it on the schedule. > > Thanks, > > Duc (dtruong) > > On Mon, Sep 17, 2018 at 8:28 PM Rico Lin > wrote: > >> *TL;DR* >> *How about a forum in Berlin for discussing autoscaling integration (as a >> long-term goal) in OpenStack?* >> >> >> Hi all, as we start to discuss how can we join develop from Heat and >> Senlin as we originally planned when we decided to fork Senlin from Heat >> long time ago. >> >> IMO the biggest issues we got now are we got users using autoscaling in >> both services, appears there is a lot of duplicated effort, and some great >> enhancement didn't exist in another service. >> As a long-term goal (from the beginning), we should try to join >> development to sync functionality, and move users to use Senlin for >> autoscaling. So we should start to review this goal, or at least we should >> try to discuss how can we help users without break or enforce anything. >> >> What will be great if we can build common library cross projects, and use >> that common library in both projects, make sure we have all improvement >> implemented in that library, finally to use Senlin from that from that >> library call in Heat autoscaling group. And in long-term, we gonna let all >> user use more general way instead of multiple ways but generate huge >> confusing for users. >> >> *As an action, I propose we have a forum in Berlin and sync up all effort >> from both teams to plan for idea scenario design. The forum submission [1] >> ended at 9/26.* >> Also would benefit from both teams to start to think about how they can >> modulize those functionalities for easier integration in the future. >> >> From some Heat PTG sessions, we keep bring out ideas on how can we >> improve current solutions for Autoscaling. We should start to talk about >> will it make sense if we combine all group resources into one, and inherit >> from it for other resources (ideally gonna deprecate rest resource types). >> Like we can do Batch create/delete in Resource Group, but not in ASG. We >> definitely got some unsynchronized works inner Heat, and cross Heat and >> Senlin. >> >> Please let me know who is interesting in this idea, so we can work >> together and reach our goal step by step. >> Also please provide though if you got any concerns about this proposal. >> >> [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations >> -- >> May The Force of OpenStack Be With You, >> >> *Rico Lin*irc: ricolin >> >> __ >> 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 >> > __ > 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 > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ 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
Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
Hi Rico, I'm the Senlin PTL and would be happy to have a forum discussion in Berlin about the future of autoscaling. Can you go ahead and start an etherpad to capture the proposed agenda and discussion items? Also, feel free to submit the forum submission so that we can get it on the schedule. Thanks, Duc (dtruong) On Mon, Sep 17, 2018 at 8:28 PM Rico Lin wrote: > *TL;DR* > *How about a forum in Berlin for discussing autoscaling integration (as a > long-term goal) in OpenStack?* > > > Hi all, as we start to discuss how can we join develop from Heat and > Senlin as we originally planned when we decided to fork Senlin from Heat > long time ago. > > IMO the biggest issues we got now are we got users using autoscaling in > both services, appears there is a lot of duplicated effort, and some great > enhancement didn't exist in another service. > As a long-term goal (from the beginning), we should try to join > development to sync functionality, and move users to use Senlin for > autoscaling. So we should start to review this goal, or at least we should > try to discuss how can we help users without break or enforce anything. > > What will be great if we can build common library cross projects, and use > that common library in both projects, make sure we have all improvement > implemented in that library, finally to use Senlin from that from that > library call in Heat autoscaling group. And in long-term, we gonna let all > user use more general way instead of multiple ways but generate huge > confusing for users. > > *As an action, I propose we have a forum in Berlin and sync up all effort > from both teams to plan for idea scenario design. The forum submission [1] > ended at 9/26.* > Also would benefit from both teams to start to think about how they can > modulize those functionalities for easier integration in the future. > > From some Heat PTG sessions, we keep bring out ideas on how can we improve > current solutions for Autoscaling. We should start to talk about will it > make sense if we combine all group resources into one, and inherit from it > for other resources (ideally gonna deprecate rest resource types). Like we > can do Batch create/delete in Resource Group, but not in ASG. We definitely > got some unsynchronized works inner Heat, and cross Heat and Senlin. > > Please let me know who is interesting in this idea, so we can work > together and reach our goal step by step. > Also please provide though if you got any concerns about this proposal. > > [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > > __ > 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 > __ 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
[openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration
*TL;DR* *How about a forum in Berlin for discussing autoscaling integration (as a long-term goal) in OpenStack?* Hi all, as we start to discuss how can we join develop from Heat and Senlin as we originally planned when we decided to fork Senlin from Heat long time ago. IMO the biggest issues we got now are we got users using autoscaling in both services, appears there is a lot of duplicated effort, and some great enhancement didn't exist in another service. As a long-term goal (from the beginning), we should try to join development to sync functionality, and move users to use Senlin for autoscaling. So we should start to review this goal, or at least we should try to discuss how can we help users without break or enforce anything. What will be great if we can build common library cross projects, and use that common library in both projects, make sure we have all improvement implemented in that library, finally to use Senlin from that from that library call in Heat autoscaling group. And in long-term, we gonna let all user use more general way instead of multiple ways but generate huge confusing for users. *As an action, I propose we have a forum in Berlin and sync up all effort from both teams to plan for idea scenario design. The forum submission [1] ended at 9/26.* Also would benefit from both teams to start to think about how they can modulize those functionalities for easier integration in the future. >From some Heat PTG sessions, we keep bring out ideas on how can we improve current solutions for Autoscaling. We should start to talk about will it make sense if we combine all group resources into one, and inherit from it for other resources (ideally gonna deprecate rest resource types). Like we can do Batch create/delete in Resource Group, but not in ASG. We definitely got some unsynchronized works inner Heat, and cross Heat and Senlin. Please let me know who is interesting in this idea, so we can work together and reach our goal step by step. Also please provide though if you got any concerns about this proposal. [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ 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
