Open Stack

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

On Wed, Mar 11, 2015 at 2:46 PM, ELISHA, Moshe (Moshe) <
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]
> 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://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://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/20150311/b1a266fc/attachment.html>