<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><br></div><div dir="ltr"><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">+1 for that.</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">I see a lot of similarities between this SIG and the self-healing
SIG, although their scopes are slightly different. </p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">In both cases, there is a need to decide when an action
should be taken (based on Ceilometer, Monasca, Vitrage etc.) what action to
take (healing/scaling) and how to execute it (using Heat, Senlin, Mistral, …).
The main differences are the specific triggers and the actions to perform.</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">I think that as a first step we should document the use
cases. </p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">Ifat</p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"><br></p></div><div dir="ltr">On Thu, Nov 29, 2018 at 9:34 PM Joseph Davis <<a href="mailto:joseph.davis@suse.com">joseph.davis@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Duc and Witek that this communication could be really good.<br>
<br>
One of the first items for a new SIG would be to define the relationship with the Self-Healing SIG.  The two SIGs have a lot in common but some important differences.  They can both use some of the same tools and data (Heat, Monasca, Senlin, Vitrage, etc) to achieve their purpose, but Self-Healing is about recovering a cloud when something goes wrong, while Autoscaling is about adjusting resources to avoid something going wrong.  Having a clear statement may help a new user or contributor understand where there interests lie and how they can be part of the group.<br>
<br>
Writing some clear use cases will be really valuable for all the component teams to reference.  It may also be of value to identify a few reference architectures or configurations to illustrate how the use cases could be addressed.  I'm thinking of stories like "A cloud with Monasca and Senlin services has 20 active VMs. When Monasca recognizes the 20 VMs have hit 90% utilization each it raises an alarm and Senlin triggers the creation of 5 more VMs to meet expected loads."  Plus lots of details I just skipped over. :)<br>
<br>
<br>
joseph<br>
<br>
<br>
On Wed, Nov 28, 2018 at 4:00 AM Rico Lin<<a href="mailto:rico.lin.guanyu@gmail.com" target="_blank">rico.lin.guanyu@gmail.com</a>>  wrote:<br>
> <br>
> I gonna use this ML to give a summary of the forum [1] and asking for<br>
> feedback for the idea of new SIG.<br>
> <br>
> So if you have any thoughts for the new SIG (good or bad) please share it<br>
> here.<br>
><br>
> [1] <a href="https://etherpad.openstack.org/p/autoscaling-integration-and-feedback" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/autoscaling-integration-and-feedback</a><br><br>
</blockquote></div></div>