[nova][ops] What should the compute service delete behavior be wrt resource providers with allocations?
Sean Mooney
smooney at redhat.com
Thu Jun 13 00:05:31 UTC 2019
On Wed, 2019-06-12 at 17:36 -0500, Eric Fried wrote:
> > 2. Change delete_resource_provider cascade=True logic to remove all
> > allocations for the provider before deleting it, i.e. for
> > not-yet-complete migrations and evacuated instances. For the evacuated
> > instance allocations this is likely OK since restarting the source
> > compute service is going to do that cleanup anyway. Also, if you delete
> > the source compute service during a migration, confirming or reverting
> > the resize later will likely fail since we'd be casting to something
> > that is gone (and we'd orphan those allocations). Maybe we need a
> > functional recreate test for the unconfirmed migration scenario before
> > deciding on this?
>
> This seems like a win to me.
>
> If we can distinguish between the migratey ones and the evacuatey ones,
> maybe we fail on the former (forcing them to wait for completion) and
> automatically delete the latter (which is almost always okay for the
> reasons you state; and recoverable via heal if it's not okay for some
> reason).
for a cold migration the allcoation will be associated with a migration object
for evacuate which is basically a rebuild to a different host we do not have a
migration object so the consumer uuid for the allcotion are still associated with
the instace uuid not a migration uuid. so technically we can tell yes
but only if we pull back the allcoation form placmenet and then iterate over
them and check if we have a migration object or an instance that has the same
uuid.
in the evac case we shoudl also be able to tell that its an evac as the uuid will
match an instance but the instnace host will not match the RP name the allcoation is
associated with.
so we can figure this out on the nova side by looking at either the instances table
or migrations table
or in the futrue when we have consumer types in placement that will
also make this simplete to do as the info will be in the allocation itself.
personally i like option 2 but yes we could selectivly force for evac only if we wanted.
>
> efried
> .
>
>
More information about the openstack-discuss
mailing list