On 25/02/15 19:15, Dolph Mathews wrote:

On Wed, Feb 25, 2015 at 5:42 PM, Zane Bitter <zbit...@redhat.com
<mailto:zbit...@redhat.com>> wrote:

    On 25/02/15 15:37, Joe Gordon wrote:



        On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell <tim.b...@cern.ch
        <mailto:tim.b...@cern.ch>
        <mailto:tim.b...@cern.ch <mailto:tim.b...@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.


__________________________________________________________________________
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

Reply via email to