[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback

Zane Bitter zbitter at redhat.com
Wed Jan 2 21:49:54 UTC 2019


On 29/11/18 1:00 AM, Rico Lin wrote:
> Dear all
> Tl;dr;
> I gonna use this ML to give a summary of the forum [1] and asking for 
> feedback for the idea of new SIG.
> We have a plan to create a new SIG for autoscaling which to cover the 
> common library, docs, and tests for cross-project services (Senlin, 
> Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). 
> And the goal is not just to have a place to keep those resources that 
> make sure we can guarantee the availability for use cases, also to have 
> a force to keep push the effort to integrate across services or at least 
> make sure we don't go to a point where everyone just do their own 
> service and don't care about any duplication.
> So if you have any thoughts for the new SIG (good or bad) please share 
> it here.

So +1, obviously (for the benefit of those who weren't at the Forum, 
I... may have suggested it?).

Even if there were only one way to do autoscaling in OpenStack, it would 
be an inherently cross-project thing - and in fact there are multiple 
options for each piece of the puzzle. I really like Rico's idea of 
building documentation and test suites to make user experience of 
autoscaling better, and the best place to host those would be a SIG 
rather than any individual project.

We know there are a *lot* of folks out there under the radar using 
autoscaling in OpenStack, so maybe a SIG will also provide a way to draw 
some of them out of the woodwork to tell us more about their use cases.

> Here I summarize our discussion in the forum session `Autoscaling 
> Integration, improvement, and feedback`. If you like to learn more or 
> input your thoughts, feel free to put it in etherpad [1] or simply 
> reply to this email.
> In the forum, we have been discussed the scope and possibility to 
> integrate effort from Heat, Senlin, and also autoscaling across 
> OpenStack to K8s. There are some long-term goals that we can start on 
> like create a document for general Autoscaling on OpenStack, Common 
> library for cross-project usage, or create real scenario cases to test 
> on our CI.
> And the most important part is how can we help users and satisfied use 
> cases without confuse them or making too much duplication effort across 
> communities/projects.
> So here's an action we agree on, is to trigger discussion for either we 
> need to create a new SIG for autoscaling. We need to define the scope 
> and the goal for this new SIG before we go ahead and create one.
> The new SIG will cover the common library, docs, and tests for 
> cross-project services (Senlin, Heat, Monasca, etc.) and cross-community 
> (OpenStack, Kubernetes, etc). And the goal is not just to have a place 
> to keep those resources that make sure we can guarantee the availability 
> for use cases, also to have a force to keep push the effort to integrate 
> across services or at least make sure we don't go to a point where 
> everyone just do their own service and don't care about any duplication.
> For example, we can have a document about do autoscaling in OpenStack, 
> but we need a place to put it and keep maintain it. And we can even have 
> a place to set up CI to test all scenario for autoscaling.
> I think it's possible to extend the definition of this SIG, but we have 
> to clear our goal and make sure we actually doing a good thing and make 
> everyone's life easier. On the other hand we also need to make sure we 
> do not duplicate the effort of other SIGs/WGs.
> Also The reason I add `ptl` tag for this ML is that this SIG or the 
> concept of `autoscaling` might be very deferent to different projects. 
> So I really wish to hear from anyone and any projects who are 
> interested in this topic.
> 
> [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
> 
> 
> 
> -- 
> May The Force of OpenStack Be With You,
> */Rico Lin
> /*irc: ricolin
> 
> 




More information about the openstack-discuss mailing list