Open Stack

New SIG request sent, please help to review it.
https://review.openstack.org/632252


On Sat, Jan 12, 2019 at 8:36 AM Rico Lin <rico.lin.guanyu at gmail.com> wrote:

>
>
> Adam Spiers <aspiers at suse.com>於 2019年1月12日 週六，上午2:59寫道：
>
>> Fine by me - sounds like we have a consensus for autoscaling then?
>
> I think “Autoscaling SIG” gets the majority vote. Let’s give it few more
> days for people in different time zones.
>
>
>>
>> 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
>>
>> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190122/989a27ff/attachment-0001.html>