All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 4/9] mg-schema-test-database: Borrow shares properly
Date: Thu, 17 Dec 2015 17:43:35 +0000	[thread overview]
Message-ID: <22130.62535.141240.627734@mariner.uk.xensource.com> (raw)
In-Reply-To: <1450373180.4053.143.camel@citrix.com>

Ian Campbell writes ("Re: [OSSTEST PATCH 4/9] mg-schema-test-database: Borrow shares properly"):
> On Thu, 2015-12-17 at 17:06 +0000, Ian Jackson wrote:
> >  	# As we copy, we note everything we're not borrowing as
> > -	# belonging to the parent db.
> > +	# belonging to the parent db.  We borrow shares of a shared
> > +	# resource.  If we borrow only some rather than all of the
> > +	# shares, neither DB will be able to unshare it.
> 
> This is what actually happens, rather than this comment explaining a thing
> we are avoiding, right?

Yes.

> I ask because although the text (and the use of "properly" in the subject)
> seems pretty clear it's the former I was surprised to find this code was
> borrowing partial shares and therefore setting up such a situation. Given
> the caveat below would it not be better to just never allow this?

I have added this to the commit message:

 Previously, the test database would be generated in a broken state:
 resources share-host/foo/{1,2,...} exist but the resource host/foo/0
 is allocated to magic/xdbref rather than to magic/shared.  This causes
 various resource allocation machinery to crash.  (Even if the host is
 entirely un-borrowed.)

I guess it might be possible for mg-schema-test-database to check that
either none or all of the shares of a host are being borrowed, but I
don't think it's worth it.  The osstest git hash in the sharetype will
in practice mostly prevent undesirable sharing of the same resource
between test and real db instances.

> I suppose that given the list of tasks to borrow came from the user
> this might be considered a "keep both pieces" situation.

Yes.  This partial sharing can only affect you if you have allocated
individual shares to the task you say you want to borrow from.

Ian.

  reply	other threads:[~2015-12-17 17:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 17:06 [OSSTEST PATCH 1/9] README.dev: Document the blessings Ian Jackson
2015-12-17 17:06 ` [OSSTEST PATCH 2/9] mg-schema-test-database: Provide some timeouts which are better for testing Ian Jackson
2015-12-17 17:19   ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 3/9] mg-schema-test-database: Wipe previous local plan data Ian Jackson
2015-12-17 17:22   ` Ian Campbell
2015-12-17 17:37     ` Ian Jackson
2015-12-17 17:42       ` Ian Campbell
2015-12-17 17:50         ` Ian Jackson
2015-12-17 18:11           ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 4/9] mg-schema-test-database: Borrow shares properly Ian Jackson
2015-12-17 17:26   ` Ian Campbell
2015-12-17 17:43     ` Ian Jackson [this message]
2015-12-17 18:08       ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 5/9] ms-planner: Improve an error message Ian Jackson
2015-12-17 17:26   ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 6/9] db_retry: Suppress an "exiting via last" warning Ian Jackson
2015-12-17 17:31   ` Ian Campbell
2015-12-17 17:48     ` Ian Jackson
2015-12-17 18:10       ` Ian Campbell
2015-12-17 18:38         ` Ian Jackson
2015-12-18 11:14           ` Ian Campbell
2015-12-18 14:39             ` Ian Jackson
2015-12-17 17:06 ` [OSSTEST PATCH 7/9] Executive DB retry: Avoid an undefined warning Ian Jackson
2015-12-17 17:31   ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 8/9] mg-allocate: Better error handling when no candidates Ian Jackson
2015-12-17 17:33   ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 9/9] mg-allocate: In planner mode, pre-check the arguments Ian Jackson
2015-12-17 17:33   ` Ian Campbell
2015-12-17 17:18 ` [OSSTEST PATCH 1/9] README.dev: Document the blessings Ian Campbell
2015-12-17 17:59   ` Ian Jackson
2015-12-17 18:12     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22130.62535.141240.627734@mariner.uk.xensource.com \
    --to=ian.jackson@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.