Open Stack

On 1/11/19 10:14 AM, Adam Spiers wrote:
> Rico Lin <rico.lin.guanyu at gmail.com> wrote:
>> Dear all
>>
>> To continue the discussion of whether we should have new SIG for 
>> autoscaling.
>> I think we already got enough time for this ML  [1], and it's time to 
>> jump to the next step. As we got a lot of positive feedbacks from ML 
>> [1], I think it's definitely considered an action to create a new SIG, 
>> do some init works, and finally Here are some things that we can start 
>> right now, to come out with the name of SIG, the definition and mission.
>> Here's my draft plan: To create a SIG name `Automatic SIG`, with given 
>> initial mission to improve automatic scaling with (but not limited to) 
>> OpenStack. As we discussed in forum [2], to have scenario tests and 
>> documents will be considered as actions for the initial mission. I 
>> gonna assume we will start from scenarios which already provide some 
>> basic tests and documents which we can adapt very soon and use them to 
>> build a SIG environment. And the long-term mission of this SIG is to 
>> make sure we provide good documentation and test coverage for most 
>> automatic functionality.
>> I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we 
>> can provide more value if there are more needs in the future. Just 
>> like the example which Adam raised `self-optimizing` from people who 
>> are using watcher [3]. Let me know if you got any concerns about this 
>> name. 
> 
> I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound 
> quite right to me, because it's not clear what is being automated. For 
> example from the outside people might think it was a SIG about CI, or 
> about automated testing, or both - or even some kind of automatic 
> creation of new SIGs ;-)
> Here are some alternative suggestions:
> - Optimization SIG
> - Self-optimization SIG
> - Auto-optimization SIG
> - Adaptive Cloud SIG
> - Self-adaption SIG
> - Auto-adaption SIG
> - Auto-configuration SIG
> 
> although I'm not sure these are a huge improvement on "Autoscaling SIG" 
> - maybe some are too broad, or too vague.  It depends on how likely it 
> is that the scope will go beyond just auto-scaling.  Of course you could 
> also just stick with the original idea of "Auto-scaling" :-)

I'm inclined to argue that limiting the scope of this SIG is actually a 
feature, not a bug. Better to have a tightly focused SIG that has very 
specific, achievable goals than to try to boil the ocean by solving all 
of the auto* problems in OpenStack. We all know how "one SIG to rule 
them all" ends. ;-)

>> And to clarify, there will definitely some cross SIG co-work between 
>> this new SIG and Self-Healing SIG (there're some common requirements 
>> even across self-healing and autoscaling features.). We also need to 
>> make sure we do not provide any duplicated work against self-healing 
>> SIG. As a start, let's only focus on autoscaling scenario, and make 
>> sure we're doing it right before we move to multiple cases. 
> 
> Sounds good!
>> If no objection, I will create the new SIG before next weekend and 
>> plan a short schedule in Denver summit and PTG. 
> 
> Thanks for driving this!