[libvirt] [PATCH v2 2/7] storage: Support "username" for "chap" type "auth"
John Ferlan
jferlan at redhat.com
Thu Jul 11 14:11:16 UTC 2013
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.
John
More information about the libvir-list
mailing list