On 10/26/2012 07:08 PM, Jiri Denemark wrote:
On Fri, Oct 26, 2012 at 15:06:19 +0530, Harsh Bora wrote:
> On 10/05/2012 05:27 PM, Paolo Bonzini wrote:
>> Il 04/10/2012 15:31, Harsh Prateek Bora ha scritto:
>>> Qemu accepts gluster protocol as supported storage backend beside others.
>>> This patch allows users to specify disks on gluster backends like this:
>>>
>>> <disk type='network' device='disk'>
>>> <driver name='qemu' type='raw'/>
>>> <source protocol='gluster'
name='volume/image'>
>>> <host name='example.org' port='6000'
transport='tcp'/>
>>> </source>
>>> <target dev='vda' bus='virtio'/>
>>> </disk>
>>>
>>> Note: In the <host> element above, transport is an optional attribute.
>>> Valid transport values are tcp, unix or rdma. If none specified, tcp is
assumed.
>>> If transport type is unix, host name specifies path to unix socket.
>>
>> I would rather add a new attribute "socket" than overload the host
name.
>> The host name for Unix sockets is really localhost.
>
> After looking into the URI infra, I realized, it is better to have the
> new attribute name as 'query' since socket=</path/to/socket> in
> qemu-gluster commandline is nothing but a query in the whole URI
> following by a '?' character.
>
> Since, the _virURI struct in libvirt also has a member 'query' for the
> query string in a URI, it makes sense to keep the XML attribute as
> generic as that so that it can be used by others for related purpose.
>
> Needless to say, users will have to specify sockets as
> <host name='example.org' port='6000' transport='unix'
> query='socket=/path/to/sock' />
Ah, this looks horrible. We really want to avoid specifying random garbage for
hostname and port in case of unix transport. What Paolo is suggesting is to
create
<host name='example.org' port='6000' transport='tcp'/>
or
<host socket='/path/to/sock' transport='unix'/>
However, I don't like this too much either. What if we add a general socket
element? In other words,
<host name='example.org' port='6000'
transport='tcp|rdma'/> or
<socket type='unix' path='/path/to/sock'/>
where the type attribute in socket element would determine what other
attributes can be used (path for unix sockets). Internally, both elements
could be described by a unified socket structure.
IIUC, a separate element for socket makes more sense if there will be
more than one socket utilized per connection (source/target pair), which
I am not really sure about.
Also, if there is a use case in future, we can always introduce a change
in schema as we are doing in this patch.
regards,
Harsh
Jirka