[openstack-dev] [Heat] Order of machines to be terminated during scale down

Maish Saidel-Keesing maishsk+openstack at maishsk.com
Wed Nov 26 13:34:49 UTC 2014


On 26/11/2014 14:50, Jay Lau wrote:
> The current behavior is not flexible to customer,  I see that we have
> a blueprint want to enhance this behavior.
>
> https://blueprints.launchpad.net/heat/+spec/autoscaling-api-resources
> https://wiki.openstack.org/wiki/Heat/AutoScaling
>
> In Use Case section, we have the following:
> ==========================================
>
>
>   Use Cases
>
>  1. Users want to use AutoScale without using Heat templates.
>  2. Users want to use AutoScale *with* Heat templates.
>  3. Users want to scale arbitrary resources, not just instances.
>  4. Users want their autoscaled resources to be associated with shared
>     resources such as load balancers, cluster managers, configuration
>     servers, and so on.
>  5. TODO: Administrators or automated processes want to add or remove
>     *specific* instances from a scaling group. (one node was
>     compromised or had some critical error?)
>  6. TODO: Users want to specify a general policy about which resources
>     to delete when scaling down, either newest or oldest
>  7. TODO: A hook needs to be provided to allow completion or
>     cancelling of the auto scaling down of a resource. For example, a
>     MongoDB shard may need draining to other nodes before it can be
>     safely deleted. Or another example, replica's may need time to
>     resync before another is deleted. The check would ensure the
>     resync is done.
>  8. *TODO: Another hook should be provided to allow selection of node
>     to scale down. MongoDB example again, select the node with the
>     least amount of data that will need to migrate to other hosts.*
>
> =======================================
>
> Item 8 is enabling customer can customize the instance to scale down.
Thanks Jay - I know that it is not available today.

What I would like to know is - what is the order that is used today?

Thanks
Maish
>
> Thanks!
>
> 2014-11-26 18:30 GMT+08:00 Pavlo Shchelokovskyy
> <pshchelokovskyy at mirantis.com <mailto:pshchelokovskyy at mirantis.com>>:
>
>     Maish,
>
>     by default they are deleted in in the same order they were
>     created, FIFO style.
>
>     Best regards,
>     Pavlo Shchelokovskyy.
>
>     On Wed, Nov 26, 2014 at 12:24 PM, Maish Saidel-Keesing
>     <maishsk+openstack at maishsk.com
>     <mailto:maishsk+openstack at maishsk.com>> wrote:
>
>         In which order are machines terminated during a scale down
>         action in an
>         auto scaling group
>
>         For example instance 1 & 2 were deployed in a stack. Instances
>         3 & 4
>         were created as a result of load.
>
>         When the load is reduced and the instances are scaled back
>         down, which
>         ones will be removed? And in which order?
>
>         From old to new (1->4) or new to old (4 -> 1) ?
>
>         Thanks
>
>         --
>         Maish Saidel-Keesing
>
>
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>     -- 
>     Pavlo Shchelokovskyy
>     Software Engineer
>     Mirantis Inc
>     www.mirantis.com <http://www.mirantis.com>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Thanks,
>
> Jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Maish Saidel-Keesing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141126/620fa2bf/attachment.html>


More information about the OpenStack-dev mailing list