1) Check for an already deleted server before deleting any. This is
related to stack convergence:
https://blueprints.launchpad.net/heat/+spec/stack-convergence
This will allow users to just delete a server they want to delete,
and then update the template to reflect reality.
2) Allow resources to be marked as critical or disposable. Critical
resources would not ever be deleted for scaling purposes or during
updates. An update would fail if there were no disposable resources.
Scaling down would just need to be retried at this point.
With those two things, TripleO can make the default "disposable" for
stateless resources, and "critical" for stateful resources. Tuskar would
just report on problems in managing the Heat stack. Admins can then
control any business cases for evacuations/retirement of workloads/etc
for automation purposes.
This is nice feature, though it looks post-I business. I would focus
more on 1) at the moment. But it's good direction.
Eventually perhaps we could use Mistral to manage that, but for now,
I think just being able to protect and manually delete important nodes
for scale down is enough. Perhaps Tuskar could even pop up a dialog
showing them and allowing manual selection.
Clint, this is exactly what I was asking for and thank you for bringing
this up. It would be awesome if we can do it. But I was told that this
is not very well possible with current TripleO approach.
So my question is - when scaling down, are we able to show user a list
of participating nodes, let him select which nodes he wants to remove
and update the template to reflect the reality then? All in Icehouse
timeframe...?
Thanks
-- Jarda
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
