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

Perry N. Myers pmyers at redhat.com
Wed Jun 4 20:51:00 UTC 2008


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.

The other thing is that the mechanism Darryl implemented is more than just 
keytab generation/retrieval.  It is also a way for the node to announce 
itself to the server w/o Avahi.  So it will run on every boot regardless.

That being said, it was my original thought in discussing this with Darryl 
to combine the hardware enumeration transmit with the HELLO/keytab step, 
and I didn't take into account the catch-22 problem.  So when I said bad 
design, I was criticizing myself there...

Perry




More information about the ovirt-devel mailing list