Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190112/4bb00bd1/attachment-0001.html>