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:pshchelokovs...@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.eli...@alcatel-lucent.com<mailto:moshe.eli...@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:sha...@redhat.com<mailto:sha...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
