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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

On 21/01/13 11:07, Ian Campbell wrote:
> On Fri, 2013-01-18 at 16:24 +0000, Roger Pau Monne wrote:
>> On 18/01/13 14:29, Ian Campbell wrote:
>>> On Fri, 2012-12-21 at 17:00 +0000, Roger Pau Monne wrote:
>>>> Add support to call hotplug scripts that use the new hotplug interface
>>>> to the low-level functions in charge of calling hotplug scripts. This
>>>> new calling convention will be used when the hotplug_version aodev
>>>> field is 1.
>>>
>>> Is there perhaps some way we can avoid users having to think about the
>>> hotplug_version?
>>>
>>> For example if we export XENBUGS_PATH as a synonym for BACKEND_PATH and
>>> arrange that the new protocol involves calling action "add" and
>>> "remove" (as well as the other new ones) do old scripts mostly Just Work
>>> because they ignore the prepare/unprepare calls? (as a small sample
>>> vif-bridge and block-nbd seem to).
>>
>> I'm afraid old scripts will return an error when called with commands
>> different than "add" or "remove", this is from block-common.sh:
>>
>> if [ "$command" != "add" ] &&
>>    [ "$command" != "remove" ]
>> then
>>   log err "Invalid command: $command"
>>   exit 1
>> fi
> 
> That's a shame.
> 
>>> 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=192.168.1.128'
>>
>> 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'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.

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
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel