Re: [Qemu-devel] [Qemu-block] block/ssh:Allow blockdev-add for ssh

[Kevin Wolf <kwolf@redhat.com>]

Am 29.09.2016 um 13:07 hat Daniel P. Berrange geschrieben:
> On Thu, Sep 29, 2016 at 12:42:34PM +0200, Kevin Wolf wrote:
> > Am 29.09.2016 um 10:07 hat Richard W.M. Jones geschrieben:
> > > On Thu, Sep 29, 2016 at 01:05:48PM +0530, Ashijeet Acharya wrote:
> > > > Hi all,
> > > > 
> > > > I was trying to convert SSH driver to support 'blockdev-add' and so
> > > > far I have tried to figure out what the struct 'BlockdevOptionsSsh' in
> > > > block-core.json should look like,
> > > > 
> > > > { 'struct': 'BlockdevOptionsSsh',
> > > >   'data': { 'tcp': 'InetSocketAddress',
> > > >              'path': 'str' } }
> > > > 
> > > > Naive question but I have to ask, Am I missing something?
> > > > 
> > > > As far as I know, ssh only supports 'tcp' right? So using
> > > > 'InetSocketAddress' should be good enough. (like the TODO says)
> > > > 
> > > > I had a discussion with Kevin about this and he thinks, maybe
> > > > 'SocketAddress' can be used too because the restriction comes from the
> > > > qemu block driver rather than the backend. He advised me to get an
> > > > opinion on this one from the maintainers of SSH.
> > > 
> > > I have no idea.
> > 
> > I searched the net a bit and it seems that SSH over Unix domain sockets
> > isn't a thing. So it might actually be okay to restrict the QEMU block
> > driver to TCP, too, and therefore use InetSocketAddress.
> > 
> > Any other opinions?
> 
> We have multiple block device drivers that all need network addresses.
> I think it'd be nice if we can use the same schema for all of them,
> even if some of them don't (currently) require certain options. 
> 
> eg rename 'GlusterServer' to 'BlockServer' and use it for all nework
> transports. Those that don't want unix support can just reject it
> at runtime, likewise those that don't need multiple-server support.
> 
> This will let mgmt apps have the same code for generating the
> blockdev options for all network based transports, instead of having
> to write different code for each.

Allowing everything and then rejecting things at runtime isn't really
the idea behind having a schema... It would also make it impossible for
libvirt to detect whether a new backend has been implemented. If we do
schemas properly and only advertise what's really there, schema
introspection can answer that question.

Kevin