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

Re: [Xen-devel] [PATCH RFC 02/10] libxl: add new hotplug interface support to hotplug script callers

On Mon, 2013-01-21 at 12:11 +0000, Roger Pau Monne wrote:
> >>> Alternatively by way of backwards compat perhaps we could provide a
> >>> wrapper script? So if today you use script="/my-custom-script" you would
> >>> switch to script="/etc/xen/hotplug-compat-wrapper /my-custom-script" and
> >>> the wrapper would shim or ignore the new calls into the old?
> >>
> >> Well, from a user point of view, this will still be the same, old
> >> hotplug scripts will be called using the "script" config option, so
> >> there will be no need to change configuration files. The only difference
> >> is that when calling hotplug scripts using the new hotplug interface
> >> users should use "method" instead of "script" in their config file, as
> >> an example this would be the diskspec line to attach a disk using the
> >> iSCSI block script:
> >>
> >> 'method=block-iscsi,vdev=xvda,target=iqn=iqn.1994-04.org.netbsd.iscsi-target:target0,portal='
> >>
> >> Users don't have to deal directly with hotplug_version, I think forcing
> >> them to user a wrapper is worse, because that will mean modifications to
> >> config files when updating.
> > 
> > But "users" of libxl do need to care about hotplug_version?
> Yes libxl users need to care about hotplug_version, I misunderstood you
> and thought you were talking about xl users, not libxl users.

I think I was initially talking about both.

> > I'm not sure what the answer is here but it would be good if everyone
> > writing a toolstack using libxl didn't have to think about what kind of
> > script each one was calling.
> > 
> > Could we perhaps mandate the new scripts have a certain comment or other
> > grepable property or that they must react without error to a particular
> > probing command line option "--are-you-a-v2-script" and have libxl probe
> > using that?
> If we choose to use think approach we can also get rid of "method",
> since libxl will be able to auto-detect script type and react
> accordingly. I don't have any preference regarding the way to do this
> auto-detection, but maybe stating that the script should return 0
> (success) when called with the action "support_v2" could be a good way.

Perhaps by way of future-proofing it should be a command
"supported-hotplug-protocols" which prints a list of supported versions,
initially just "2" for new scripts with failure taken to mean "1".
Combined with also setting $XEN_HOTPLUG_PROTOCOL=<N> that would give us
some scope for future evolution.

> I prefer this rather that having a comment somewhere, since hotplug
> scripts can be in any kind of programming language (or even in binary
> form AFAIK), this could become more complicated that it seems now.


Xen-devel mailing list



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