[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH OSSTEST 04/11] TestSupport: introduce set_host_prop

On Fri, Jul 28, 2017 at 04:39:04PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST 04/11] TestSupport: introduce 
> set_host_prop"):
> > This is from the code in mg-hosts. Switch cmd_setprops to use the
> > newly introduced function.
> I think this needs to be abstracted through jobdb.  Certainly these
> SQL statements operating on the host_properties table are valid in
> Executive mode only and shouldn't appear in TestSupport.pm.
> If you are lucky then mg-hosts runs with $mjobdb set.  In which case
> you make it call $mjobdb->set_host_prop.
> I considered asking you to make a wrapper in TestSupport or
> Osstest.pm.  But: actually, I think the wrapper in TestSupport ought
> to take a $ho, not a hostname.  That would guarantee that a ts-*
> script which used it had called selecthost and had the host allocated.
> Whereas mg-hosts setprops is exceptional: it wants to be able to set
> the property on a host without the user having allocated it.  I think
> that justifies the "back door" entry via $mjobdb.
> What do you think ?

That sounds fine. I agree that the approach taken here is too drastic.
For once, the set_host_property should take a $ho, and then it should
hide all this in mhostdb (so that it works in standalone mode).

IMHO, I think the right approach is to leave mg-hosts as it is now,
and implement a set_property in HostDB/{Executive/Static}.pm and
implement a helper in TestSupport that makes use of it
($mhostdb->set_property(...)), do you agree?

Thanks, Roger.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.