Configuration parameter in Volumen.create()

[MatiasVara]

Hello, for a volumen plugin I require to have a configuration field in which I need to pass some parameters. The spec defines it here, however, I can't find it in the implementation. My plan would be to add it but I would like to ask if you had the same problem, and in that case, how did you approach it.

Regads,

[edwintorok]

See here for an example of how to define a plugin: https://github.com/xapi-project/xapi-storage/blob/master/python/examples/volume/org.xen.xapi.storage.simple-file/sr.py#L42-L58

That is for an SR plugin though, a Volume plugin takes a URI not a configuration (but you can encode the configuration you need into the URI). It is just the documentation that takes you to the wrong place: when you click Volume.create it takes you to the docs about SR.create (because they're both called create). If you scroll down you should be able to see the actual Volume.create API.

And see the example here might also be useful for getting started: https://github.com/xapi-project/xapi-storage/tree/master/python/examples

[MatiasVara]

Thanks Edwin for your answer. If I understand you correctly, I should encode the configuration into a URI and parse it during volumen.create(). The issue is that, for a given SR, I require to pass a specific configuration for each invocation to volumen.create(), i.e., volumen.create() is invoked multiple times for a SR. For the moment, we are relying on a workaround by using the description field, which is unique for each volumen.create() (see this here). The description is used to define the directory that is going to be shared between the guest and the host. We know this information only when volumen.create() is called. However, I was wondering if there is a better way to do this. Maybe I am missing something from the overall architecture of the plugin.

[MatiasVara]

Hello Edwin, I did not hear from you for a while. In the following days, I am going to submit a PR to the specification to add a configuration field at the volumen.create() method. If you have a better way to do it, feel free to let me know.

[MarkSymsCtx]

I think you're approaching this from the wrong direction. It is the responsibility of the Storage Management plugin to tell the caller where the volume is so that it can be correctly attached to the VM, specifically the datapath plugin must provide this information when the attach and/or activate operations are performed.

[edwintorok]

See the example SR/volume plugins . It should be possible to encode the configuration that you need in the URI that you return, based on the parameters that you receive. I think all the APIs have the necessary configuration parameters passed to them already.

That is what the example plugin and our own SR plugin does. Your plugin is the only one processing this URI, so you get to define what each parameter would mean (although if there is a standard/RFC for URIs for your particular SR it'd probably be best to follow that).

If you need configuration specific to the volume then you can use attributes for that, see the set API. We use that for things like reset-on-boot. But if all you need is to pass one configuration parameter that is common to all volumes in an SR then encoding that into the SR URI is probably the way to go as the example does.

[MatiasVara]

Thanks both for your answers. As Edwin proposed, I am going to use set to define an attribute that is specific to the volume. In such a case, what would the xe command issue the corresponding volume.set()? I tried with xe vdi-param-set uuid=xxxxx dir=pepo without success.

[MatiasVara]

I have fixed this issue by modifying the way the volume driver is triggered to create vdis. Roughly speaking, I let the user create symlinks in a special folder that the volume driver uses to trigger the creation of the vdis. To do so, the user issues a xe sr-scan on the sr. I couldn't use the set method since I could not trigger that method from a xe command. I could not figure out how the xapi decides to use volume.set() for certain attributes. Also, I was not sure if I should query the xapi from the volume driver so I avoided any solution of that sort. I noted that the command xe sr-scan ends up triggering sr.ls() and then sr.stat(). This may help someone working on a similar issue.