[Ovirt-devel] [PATCH]: Fix ovirt-identify-node to work at boot time

[Perry N. Myers]

Daniel P. Berrange wrote:
> On Wed, Jun 04, 2008 at 04:51:00PM -0400, Perry N. Myers wrote:
>> Daniel P. Berrange wrote:
>>> On Wed, Jun 04, 2008 at 04:19:30PM -0400, Darryl Pierce wrote:
>>>> Perry N. Myers wrote:
>>>>> Catch-22 problem....  if you have suggestions let me know.
>>>>>
>>>>> libvirt requires a keytab to work properly.  The code that is executing 
>>>>> is code to GET the keytab.  Therefore this must execute prior to 
>>>>> libvirt. Bad design...
>>>>>
>>>>> We're probably going to change the startup sequence to be like this 
>>>>> instead (but this will have to happen after summit)
>>>>>
>>>>> 1. ovirt init script starts so keytab could get retrieved
>>>>> 2. libvirt start
>>>>> 3. another ovirt initscript starts to give hardware info to ovirt server
>>>>>
>>>>> Thoughts?
>>>> In my last email, WRT the indentify process, I was under the impression 
>>>> we wanted to have the hardware information submitted when the node 
>>>> identified itself. Is that incorrect in my understanding?
>>> Ideally the keytab fetching will be a onetime process, persisted on the
>>> machine once fetched. Hardware info will want to be re-submitted on every
>>> boot because admin may have altered the hardware across reboots. So these
>>> should be considered separate submission steps.
>> Well... ideally you are correct.
>>
>> However, in practice oVirt may be deployed on machines with 0 local 
>> storage and no TPM.  And in these cases the keytab needs to be retrieved 
>> on every boot.  So our design is to use the local keytab if present, if 
>> not, ask for it.
> 
> That's fine - I still think the two steps should be separated as you show
> above, with libvirt in the middle :-) Other things which are kerberos 
> enabled can potentially be dependant on the keytab setup besides libvirt/
> ovirt, so it makes sense to allow that to be completed as early in boot
> as possible.

Yep, Agreed.

Perry