[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v2 0/5] Introduce API for dumping domain IP addresses

On Tue, Jul 31, 2012 at 05:38:31PM +0100, Daniel P. Berrange wrote:
> On Tue, Jul 31, 2012 at 11:22:09AM +0800, Daniel Veillard wrote:
> > > So do we have a consensus on this? The first version expose guest IP via
> > > public struct, while this one returns an XML doc. Which one should we
> > > prefer?
> > 
> >   It seems to me people suggesting either ways
> >    1/ struct if we just return the IP adress[es]
> >    2/ XML if we want to expand all the other informations about the
> >       interface
> > 
> > At this point I would think we are not really in a good situation to
> > extract and expose all the interface settings as seen from the guest
> > and as Dan said it's more something to be done on the guest agent,
> > that interface is a backup in the absence of agent or a way to bootstrap
> > communication with the guest. I think v1 does this fine, though I would
> > agree with Eric feedback on the API changes, I would also suggest -1
> > as being the error failure code for this API.
> > Then later if we can get full client interfaces viewpoint, as seen from
> > the guest (is there an API for this in VMWare, we ought to be able to do
> > it for LXC) then providing a second extensible API returning an XML
> > could be added, but I think the core API need now it be able to easilly
> > extract the IP(s) of the guest, and XML while being more flexible for
> > future use would get in the way.
> > 
> >   So my take would be to refine v1, and based on feedback of v1,
> > availability of informations in various drivers, then provide an
> > XML extensible version if there is a need and a good way to provide
> > the full information set.
> I think I've already mentioned I had  a preference for v1 struct approach.
> If we did go for th v2 XML approach, then I'd want us to align with the
> virInteface XML schema for reporting interface configuration, instead of
> creating a new schema.
> FWIW, I don't think it would be the end of the world if we added a
> struct based API now, and then *also* added a XML based API at a
> later date (should it become required)

  okay, we agree,


Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]