On 07/10/2013 10:49 AM, Daniel P. Berrange wrote:
On Tue, Jul 09, 2013 at 03:10:46PM -0400, John Ferlan wrote:
> To be consistent with "ceph" types for storage "auth" elements,
allow
> "username" to be used as an "auth" attribute name for
"chap" types.
> Continue to allow "login" for backwards compatibility when reading the
XML,
> but when writing the XML use "username".
Hmm, so the schema for 'chap' auth is utterly awful.
While we have parsed this schema for a while, nothing in the libvirt
codebase has ever used 'chap' auth.
As such I think we have reasonable grounds for just discarding the
existing code for parsing 'chap' auth and doing it right. ie use
the same terminology as 'ceph' and do not include the 'password'
value in the XML at all.
Thoughts ?
Daniel
Don't have the historical perspective w/r/t when it was added - even
looking through gitk I can find that parsing in for quite a while (even
in the src/storage_conf.c). I admit I found it quite confusing to read
and attempt to document.
Other than having to actually make the changes :-), I see no reason why
the storage_conf needs to be different and support numerous combinations
based on type...
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>
That is there'd be no reason for 'type' in the XML nor 'password'.
The
'login' goes away and the 'username' becomes required.
Should we search for 'login' or 'password' when parsing and issue some
sort of warning/message via VIR_WARN or virReportError? Ditto for
'type'? Or do we just silently ignore? Cannot imagine someone putting
a plain text password in the XML file, but then again I also know what
happens when you assume something...
John