On Mon, Jul 23, 2012 at 08:34:30AM -0600, Eric Blake wrote: > On 07/23/2012 03:20 AM, Stefan Hajnoczi wrote: > >> > >> So without the capability to pass custom options to block drivers, am I > >> forced > >> to keep extending the file= with more and more options ? > >> > >> file=gluster:transport:server:port:volname:image ? > >> > >> Looks ugly and not easy to make any particular option optional. If needed > >> I can > >> support this from GlusterFS backend. > > > > Kevin, Markus: Any thoughts on passing options to block drivers? > > Encoding GlusterFS options into a "filename" string is pretty > > cumbersome. > > On 07/23/2012 03:28 AM, ronnie sahlberg wrote:> Why not use > > > > -drive file=gluster://server[:port]/volname/image > > At which point, options can fit into this URI scheme: > > -drive file=gluster://server:port/volname/image?option1=foo&option2=bar > > where anything after the ? of the URI can introduce whichever options > you need.
The URI covered everything and left only transport as the option, which could be made part of the URI itself ? So looks like we have two options: gluster://server[:port]/[transport]/volname/image vs gluster:server:[port]:[transport]:volname:image Unless there is a strong preference on one over the other, I am inclined to go with the latter (colon based) approach and expect user to provide double colons (::) wherever any default value needs to be specified. Eg 1. gluster:localhost:::test:/a.img Eg 2. gluster:localhost:0:socket:test:/a.img Regards, Bharata.