oVirt Node designs for stateless operation and 3rd party plugins

[Itamar Heim]

On 12/06/2011 04:11 PM, Perry Myers wrote:
> Hi Geoff,
>
> Thanks for weighing in on this.  Let me preface my comments below by
> saying that I think by and large we're on the same page with the
> design/intent of stateless here.  I just think you may have some
> confusion about terminology and what stateless will imply/not imply for
> the end user.  I'll try to clarify below so that we can get on the same
> page.

+1 - thanks for the input and insights.
one more point below
...

>> *  Configuration server
>>
>> This should be part of the engine.   It should know the complete
>> configuration of a node, right down to hypervisor 'firmware' image.  The
>> process should be 2-way.  An admin should be able to 'pull' the
>> image/config from an operational and accessible node and new
>> configurations/images should be pushable to it.
>
> It will be collocated with the Engine, but we will design it in such a
> way that it can be run independently from the oVirt Engine.  There are
> several reasons for this:
>
> 1. re-usability outside of the oVirt context
> 2. scaling multiple config servers for different areas of the datacenter
> 3. perhaps one part of the datacenter is comfortable using a config
>     server and another is not.  You could co-locate the config server
>     with the portion of Nodes that are using DNS SRV/DHCP, etc and keep
>     them physically separate from the Nodes that are using static config
>     and local disks for configuration
>
> Keep in mind that most of the Node configuration is _already_ done by
> oVirt Engine (advanced storage config, network config, vm information).
>   The only thing that this config server will need to store are:
>
> * config of the mgmt network interface
> * config of vdsm so that the Node can talk back to the oVirt Engine
> * config of the local passwd file
>
> Most everything else can/is applied dynamically by oVirt Engine sending
> config to vdsm.  So this config server really is just bootstrapping for
> the basic stuff, and we let the oVirt Engine handle everything else more
> complex.
>
>> I really don't think this needs to be a separate server to the engine.
>
> Noted.  I'd be interested to see if others have an opinion here.

I understand deploying config as a separate service than the engine, but 
can it optionally use the engine to get what it need to avoid the need 
for an extra db to sync/upgrade/etc.
a deployment in a remote site could cache the information to provide it 
in case the engine is not responding (so the node can finish booting to 
be used by the engine next time it is running).

so you could configure it to use a local store, but in a ovirt-engine 
deployment it would just be a service focusing on the relevant 
communication method and delivery of image if needed.

I think that would make deployment/life cycle management much easier.