[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend |
Date: |
Fri, 7 Sep 2012 10:19:35 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Sep 07, 2012 at 08:54:02AM +0530, Bharata B Rao wrote:
> On Thu, Sep 06, 2012 at 04:47:17PM +0100, Daniel P. Berrange wrote:
> > 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
> ^why 3 /// here ? volname is not a path, but image is.
The first 2 '/' are the protocol/hostname separator and the 3rd
/ is the hostname/path separator. Since there is no hostname in
this example, you get ///
> So when transport=socket or rdma, is it acceptable to still use the following
> format ?
>
> gluster://server[:port]/volname/path/to/image[?transport=...]
Of course.
> With that, the different options possible are
>
> unix -
> gluster://testvol/dir/a.img?transport=unix&sockpath=/tmp/glusterd.socket
> ipv4 - gluster://1.2.3.4:0/testvol/dir/a.img?transport=socket
I assume you intend 'transport=socket' to be optional here
> ipv6 - gluster://[1:2:3:4:5:6:7:8]:0/testvol/a.img
> hostname - gluster://example.org/testvol/dir/a.img
> rdma - gluster://1.2.3.4:0/testvol/a.img?transport=rdma
>
> Does this look complete from the specification point of view ?
Yes, this looks like a reasonable use of URIs.
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 :|
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Avi Kivity, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Bharata B Rao, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Daniel P. Berrange, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, ronnie sahlberg, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Avi Kivity, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Bharata B Rao, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend,
Daniel P. Berrange <=
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Kevin Wolf, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Bharata B Rao, 2012/09/12
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/12
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Kevin Wolf, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Daniel P. Berrange, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/07