On Fri, Sep 07, 2012 at 12:00:50PM +0200, Kevin Wolf wrote: > Am 06.09.2012 17:47, schrieb Daniel P. Berrange: > > On Thu, Sep 06, 2012 at 09:10:04PM +0530, Bharata B Rao wrote: > >> On Thu, Sep 06, 2012 at 11:29:36AM +0300, Avi Kivity wrote: > >>> On 08/14/2012 12:58 PM, Kevin Wolf wrote: > >>>> > >>>>> While we are at this, let me bring out another issue. Gluster supports 3 > >>>>> transport types: > >>>>> > >>>>> - socket in which case the server will be hostname, ipv4 or ipv4 > >>>>> address. > >>>>> - rdma in which case server will be interpreted similar to socket. > >>>>> - unix in which case server will be a path to unix domain socket and > >>>>> this > >>>>> will look like any other filesystem path. (Eg. /tmp/glusterd.socket) > >>>>> > >>>>> I don't think we can fit 'unix' within the standard URI scheme (RFC > >>>>> 3986) > >>>>> easily, but I am planning to specify the 'unix' transport as below: > >>>>> > >>>>> gluster://[/path/to/unix/domain/socket]/volname/image?transport=unix > >>>>> > >>>>> i,e., I am asking the user to put the unix domain socket path within > >>>>> square brackets when transport type is unix. > >>>>> > >>>>> Do you think this is fine ? > >>>> > >>>> Never saw something like this before, but it does seem reasonable to me. > >>>> Excludes ] from the valid characters in the file name of the socket, but > >>>> that shouldn't be a problem in practice. > >>> > >>> Bikeshedding, but I prefer > >>> > >>> gluster:///path/to/unix/domain/socket:/volname/image?transport=unix > >> > >> So if the unix domain socket is /tmp/glusterd.socket, then this would look > >> like: > >> > >> gluster:///tmp/glusterd.socket:/volname/image?transport=unix. > >> > >> So you are saying : will the separator b/n the unix domain socket path > >> and rest of the URI components. > >> > >> Unless you or others strongly feel about this, I would like to go with > >> [ ] based spec, which I feel is less prone to errors like missing a colon > >> by mistake :) > >> > >>> > >>> as being more similar to file://, or even > >>> > >>> gluster:///path/to/unix/domain/socket/volname/image?transport=unix > >>> > >>> with the last two components implied to be part of the payload, not the > >>> path. > >> > >> Note that image is a file path by itself like /dir1/a.img. So I guess it > >> becomes difficult to figure out where the unix domain socket path ends > >> and rest of the URI components begin w/o a separator in between. > > > > IMHO this is all gross. URIs already have a well defined way to provide > > multiple parameters, dealing with escaping of special characters. ie query > > parameters. The whole benefit of using URI syntax is to let apps process > > the URIs using standard APIs. We should not be trying to define some extra > > magic encoding to let us stuff 2 separate parameters into the path component > > since that means apps have to now write custom parsing code again. Either > > the UNIX socket path, or the volume path should be in the URI path, not > > both. The other part should be a URI parameter. I'd really expect us to > > use: > > > > gluster:///volname/image?transport=unix&sockpath=/path/to/unix/sock > > I think doing it the other way round would be more logical: > > gluster+unix:///path/to/unix/sock?image=volname/image > > This way you have the socket first, which you also must open first. > Having it as a parameter without which you can't make sense of the path > feels a bit less than ideal.
The issue here is that the volume/path/to/image part is something that is required for all gluster transports. The /path/to/unix/sock is something that is only required for the unix transport. To have consistent URI scheme across all transports, you really want the volume/path/to/image bit to use the URI path component. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
