Open Stack

Fine by me - sounds like we have a consensus for autoscaling then?

Melvin Hillsman <mrhillsman at gmail.com> wrote:
>+1 SIGs should have limited scope - shared interest in a particular area -
>even if that area is something broad like security the mission and work
>should be specific which could lead to working groups, additional SIGs,
>projects, etc so I want to be careful how I word it but yes limited scope
>is the ideal way to start a SIG imo.
>
>On Fri, Jan 11, 2019 at 11:14 AM Duc Truong <duc.openstack at gmail.com> wrote:
>
>> +1 on limiting the scope to autoscaling at first.  I prefer the name
>> autoscaling since the mission is to improve automatic scaling.  If the
>> mission is changed later, we can change the name of the SIG to reflect
>> that.
>>
>> On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <openstack at nemebean.com> wrote:
>> >
>> >
>> >
>> > 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!
>> >
>>
>>
>
>-- 
>Kind regards,
>
>Melvin Hillsman
>mrhillsman at gmail.com
>mobile: (832) 264-2646