Open Stack

On 25/02/15 19:15, Dolph Mathews wrote:
>
> On Wed, Feb 25, 2015 at 5:42 PM, Zane Bitter <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> wrote:
>
>     On 25/02/15 15:37, Joe Gordon wrote:
>
>
>
>         On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell <Tim.Bell at cern.ch
>         <mailto:Tim.Bell at cern.ch>
>         <mailto:Tim.Bell at cern.ch <mailto:Tim.Bell at cern.ch>>> wrote:
>
>
>              A few inline comments and a general point
>
>              How do we handle scenarios like volumes when we have a
>         per-component
>              janitor rather than a single co-ordinator ?
>
>              To be clean,
>
>              1. nova should shutdown the instance
>              2. nova should then ask the volume to be detached
>              3. cinder could then perform the 'project deletion' action as
>              configured by the operator (such as shelve or backup)
>              4. nova could then perform the 'project deletion' action as
>              configured by the operator (such as VM delete or shelve)
>
>              If we have both cinder and nova responding to a single message,
>              cinder would do 3. Immediately and nova would be doing the
>         shutdown
>              which is likely to lead to a volume which could not be
>         shelved cleanly.
>
>              The problem I see with messages is that co-ordination of
>         the actions
>              may require ordering between the components.  The
>         disable/enable
>              cases would show this in a worse scenario.
>
>
>         You raise two good points.
>
>         * How to clean something up may be different for different clouds
>         * Some cleanup operations have to happen in a specific order
>
>         Not sure what the best way to address those two points is.
>         Perhaps the
>         best way forward is a openstack-specs spec to hash out these
>         details.
>
>
>     For completeness, if nothing else, it should be noted that another
>     option is for Keystone to refuse to delete the project until all
>     resources within it have been removed by a user.
>
>
> Keystone has no knowledge of the tenant-owned resources in OpenStack
> (nor is it a client of the other services), so that's not really feasible.

As pointed out above, Keystone doesn't have any knowledge of how to 
orchestrate the deletion of the tenant-owned resources either (and in 
large part neither do the other services - except Heat, and then only 
for the ones it created), so by that logic neither option is feasible.

Choose your poison ;)

>
>     It's hard to know at this point which would be more painful. Both
>     sound horrific in their own way :D
>
>     cheers,
>     Zane.