On Thu, Jul 11, 2013 at 10:11:16AM -0400, John Ferlan wrote: > On 07/10/2013 12:04 PM, Daniel P. Berrange wrote: > > On Wed, Jul 10, 2013 at 11:51:42AM -0400, John Ferlan wrote: > >> On 07/10/2013 10:49 AM, Daniel P. Berrange wrote: > >>> On Tue, Jul 09, 2013 at 03:10:46PM -0400, John Ferlan wrote: > ...<snip> > >> > >> To be sure we're on the same page, the storage_conf XML then becomes > >> > >> <auth username='someuser'> > >> <secret type='[ceph|iscsi]' [usage='mypassed'|uuid='someuuid']/> > >> </auth> > > > > Actually I think the schema is: > > > > <auth username='someuser' type='[ceph|chap]'> > > <secret [usage='mypassed'|uuid='someuuid']/> > > </auth> > > > >> That is there'd be no reason for 'type' in the XML nor 'password'. The > >> 'login' goes away and the 'username' becomes required. > > > > I think you still want to keep 'type' in the XML, since if iSCSI adds > > a different auth mechanism that isn't 'chap', then we have the ability > > to represent that using a new type. > > > > The <secret> XML has an existing 'type' which is 'ceph', 'iscsi' (eg, > CHAP), or 'volume' and I just figured that since the <auth> XML requires > 'username' and the <secret> subelement with a mandatory 'type' > attribute, then that would cover the needs. > > See: http://libvirt.org/formatdomain.html#elementsDisks > > I'm not objecting to using the 'type' in the <auth> XML, just noting > that's it's a duplication of an attribute, although I suppose if some > authentication mechanism was added in the future that didn't use the > secret element, then having a type present make things easier. Hmm, we're comparing two different XML schemas. You're quoting the schema for the <disk> element's <auth> tag in the guest XML. I'm referring to the schema for the <auth> tag in the storage pool XML 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list