[et-mgmt-tools] [RFC] virtinst: build libvirt storage xml

Daniel P. Berrange berrange at redhat.com
Fri Jul 25 16:34:51 UTC 2008


On Fri, Jul 25, 2008 at 12:27:29PM -0400, Cole Robinson wrote:
> Daniel P. Berrange wrote:
> > On Fri, Jul 25, 2008 at 12:01:15PM -0400, Cole Robinson wrote:
> >> Daniel P. Berrange wrote:
> >>  >> The general workflow is as follows:
> >>>> =========================================
> >>>> import virtinst.Storage.StoragePool as sp
> >>>>
> >>>> # This gives the appropriate class for the specified pool type
> >>>> pool_class = sp.get_pool_class(sp.TYPE_FOO)
> >>>>
> >>>> # Only required params are a conn/uri and name. Default formats
> >>>> # and target paths have default values, but source paths/
> >>>> # devices and hostnames obviously have no sensible default, but
> >>>> # they still aren't required for object instantiation
> >>>> pool = pool_class(name="foo", uri="xen:///")
> >>> Should proably allow a existing connection to be passed in, otherwise
> >>> this class has to deal with authentication issues too.
> >>>
> >> I didn't show it in the example, but passing a connection is allowed.
> >>
> >> On a side note, we should add support for openAuth in virtinst,
> >> everything is just hardcoded to use libvirt.open at the moment.
> > 
> > No, that's exactly why we shouldn't take a URI. openAuth requires user
> > interaction, so that's unavoidably application specific. We just need
> > a helper in virtinst/cli.py for the command line tools to use to create
> > their connection object, and virt-manager already knows how to do
> > authentication. So everything should just pass ina connection object
> > instead of URI.
> > 
> > Daniel
> 
> Ahh okay, that makes sense. I'll remove the option to pass a URI then,
> since we really shouldn't even encourage passing a URI and expecting
> the library to open it.

Just don't remove it from the existing Guest modules, because Koan is
relying on this API to remain stable & since Koan is local only it
doesn't have to worry about auth.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the et-mgmt-tools mailing list