Re: [PATCH] Prevent xend from starting duplicate domains

[Christian Limpach <christian.limpach@gmail.com>]

On 9/16/05, Dan Smith <danms@us.ibm.com> wrote:
> CL> We should fix that check instead of adding another check.
> 
> I agree that there should be one check, but it seems counter-intuitive
> (to me) to have that check where it is.  That's the reason I hadn't
> noticed it before.
> 
> It seems strange to have a container class (XendDomain) that
> instantiates an item object which then gets an instance of the
> container to check for another domain with the same name.  Why not
> have the container itself do the duplicate check?  I would argue that
> the existing model is bad because the item class could not be placed
> in another container.  Further, the container is enforced as a set by
> the items that go in it, instead of the container itself.
> 
> If others agree, I'd be happy to submit a patch that moves the check
> out of the item class and into the container class.

I agree, go for it.  You'll have to check both in the create and
restore cases.  I don't think we need to check on recreate, we can
assume a consistent store...

> CL> Could you try the attached patch which removes the check if a
> CL> domain "is terminated" and thus allows creation of a domain with
> CL> the same name?
> 
> I did test the patch and it does prevent corruption of the list.

I'm happy with removing the check, but I wonder if we're not masking
the fact that we set the domain to terminated state when it's not yet
in that state.  Yeah, looks like we should only set the state to
terminated once we've completed device cleanup.
Of course we must have some other bug which you hit when we have
domains in terminated state and you want to create a new domain of the
same name.  Maybe renaming the domain when we set the terminated state
is the solution for that...

    christian