WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Prevent xend from starting duplicate domains

To: Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Prevent xend from starting duplicate domains
From: Christian Limpach <christian.limpach@xxxxxxxxx>
Date: Sat, 17 Sep 2005 00:47:45 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Sep 2005 23:45:30 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/LLR+qruEvTNgDHl8BK4Aotyr28txGIyi1PN5Vgit9yV5oM57zw4pFW0Tohj//dh/VPQ4dYXlWYJLpgjRWYUrNTtiIXBY7QiC3KcvsfV1rdJyGe9nWtKANxcQVnKt/CPRuGLZApfB6uJe4X2ol0eRyIr1gKIzXJA6PKF6ymAQU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <87hdckhbme.fsf@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87d5ncsksl.fsf@xxxxxxxxxx> <3d8eece205091612407ddf69a9@xxxxxxxxxxxxxx> <87hdckhbme.fsf@xxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 9/16/05, Dan Smith <danms@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel