[all][meta-sig] New Automatic SIG (continue discussion)

Duc Truong duc.openstack at gmail.com
Fri Jan 11 17:14:03 UTC 2019


+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!
>



More information about the openstack-discuss mailing list