[openstack-dev] [nova][heat] Autoscaling parameters blueprint

ELISHA, Moshe (Moshe) moshe.elisha at alcatel-lucent.com
Thu Mar 12 12:10:58 UTC 2015


This is a very nice idea but I’m afraid that the index is not the only parameter that is different between the instances.
I will write down the full use case so we could continue the discussion. Thanks!


From: Pavlo Shchelokovskyy [mailto:pshchelokovskyy at mirantis.com]
Sent: יום ד 11 מרץ 2015 14:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

Hi,

as you have a separate monitoring solution (not Ceilometer), it seems you can use ResourceGroup instead of AutoscalingGroup and issue heatclient/rest calls to do a stack-update with desired size of the group when needed. The group members will be numbered, and as already said you can also control the removal. One possible downside is that AFAIR the numbers would not be reused on subsequent scale-down/ups.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com<http://www.mirantis.com>

On Wed, Mar 11, 2015 at 2:46 PM, ELISHA, Moshe (Moshe) <moshe.elisha at alcatel-lucent.com<mailto:moshe.elisha at alcatel-lucent.com>> wrote:
I am familiar of the removal policies. Thanks!

Our use case for parameters on scale out is as follows:

Every server has a unique index that identifies it.
The first server has an index of 1, the second has an index of 2, etc.
The index of each server must exist prior to the configuration phase of the server.

This use case is an outcome of a virtualization process for an NFV application.
In the past this application was scaled manually by adding physical cards into slots - the index is the slot number.
In order to allow a smooth and fast transition of the app into the cloud - the requirement is to stay with the same architecture.


The current suggested solution is as follows:

The HOT will be created with an AutoScalingGroup and two ScalingPolicies for scale out and scale in.
Like many other NFV applications, this application also has a Life Cycle Manager of its own that monitors and decides when to scale.
When scale is needed, the LCM will invoke the alarm_url exposed by these ScalingPolicies while providing the server index for the newly created server.

The index is just one example of a parameter needed at scale out - there can be others.
Much more design is needed when the desired_capacity > 1 or  the scaling_adjustment > 1 or in percentage but let's first agree that the use case is OK.


-----Original Message-----
From: Steven Hardy [mailto:shardy at redhat.com<mailto:shardy at redhat.com>]
Sent: Wednesday, March 11, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

On Wed, Mar 11, 2015 at 09:01:04AM +0000, ELISHA, Moshe (Moshe) wrote:
>    Hey,
>
>
>
>    Can someone please share the current status of the "Autoscaling signals to
>    allow parameter passing for UserData" blueprint -
>     https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters.

This is quite old, and subsequent discussions have happened which indicate a slightly different approach, e.g this thread here where I discuss approaches to signalling an AutoScalingGroup to remove a specific group member.  As Angus has noted, ResourceGroup already allows this via a different interface.

http://lists.openstack.org/pipermail/openstack-dev/2014-December/053447.html

>    We have a very concrete use case that require passing parameters on scale
>    out.
>
>    What is the best way to revive this blueprint?

Probably the first thing is to provide a more detailed description of your use-case.

I'll try to revive the AutoScalingGroup signal patch mentioned in the thread above this week, it's been around for a while and is probably needed for any interface where we pass data in to influence AutoScalingGroup adjustment behaviour asynchronously (e.g not via the template definition).

https://review.openstack.org/#/c/143496/

Steve

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150312/409b8aae/attachment.html>


More information about the OpenStack-dev mailing list