Open Stack

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