[node-devel] Needed: Node and Engine cooperation

[Moti Asayag]

----- Original Message -----
> From: "Fabian Deutsch" <fabiand at redhat.com>
> To: "arch" <arch at ovirt.org>, "node-devel" <node-devel at ovirt.org>
> Sent: Monday, October 21, 2013 8:45:41 PM
> Subject: [node-devel] Needed: Node and Engine cooperation
> 
> Hey,
> 
> with the extraction of the oVirt Engine / VDSM specific bits from Node
> in it's 3.0 release, oVirt Node became unaware of when it is being
> managed.
> Pre-3.0 Node (it's TUI) had specific knowledge about what configuration
> files existed when it was registered to Engine. This is not the case in
> Node 3.0 anymore. And this leads to problems. E.g. a user removing
> Engines network layout.
> 
> A new way is needed to pass informations between the management instance
> and Node's core. This informations are needed e.g. to prevent the user
> from accidentally destroying Engines network layout on a Node.

How is it different from an admin connecting to non ovirt-node host and manually
dis-configure its network ? 

I'm not sure we need to prevent from the administrator to perform any manual
changes on the host. Perhaps the TUI could reflect the networks name by querying 
vdsm/libvirt in the same sense as the engine does so the user will be aware which 
interfaces carry logical networks.

> 
> I've opened a bug [0] to suggest a way of sharing this kind of
> informations.
> 
> The idea is that Node and the management instance - Engine - share a set
> of common configuration keys in /etc/default/ovirt to pass the relevant
> bit's to Node.
> For now I thought about this three keys:
> 
> 
> OVIRT_MANAGED_BY=<vendor>
> This key is used to (a) signal the Node is being managed and (b)
> signaling who is managing this node.
> 
> OVIRT_MANAGED_IFNAMES=<ifname>[,<ifname>,...]
> This key is used to specify a number (comma separated list) of ifnames
> which are managed and for which the TUI shall display some information
> (IP, ...).
> This can also be used by the TUI to decide to not offer NIC
> configuration to the user.
> 
> OVIRT_MANAGED_LOCKED_PAGES=<pagename>[,<pagename>,...]
> (Future) A list of pages which shall be locked e.g. because the
> management instance is configuring the aspect (e.g. networking or
> logging).
> 
> 
> The third one (OVIRT_MANAGED_LOCKED_PAGES) needs a tighter integration
> and might be relevant in the future, but the first two should really be
> implemented quickly for the reasons given above.
> 
> It is quit elate in the development process but probably worth to think
> about getting this into 3.3.1, to prevent all sorts of (accidentally)
> user-driven collisions between Node and Engine.
> 
> Thoughts?
> 
> Greetings
> fabian
> 
> ---
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1021647
> 
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel
>