Open Stack

> 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