[node-devel] Needed: Node and Engine cooperation

[Fabian Deutsch]

Am Sonntag, den 27.10.2013, 06:58 -0400 schrieb 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 ? 

You are right that there is not really a difference between those both
scenarios.
If vdsm can cope with this then this shouldn't be a problem.
My assumption was that vdsm had problems when the network configuration
got changed on a different way than through vdsm.
If vdsm is fine with this - the network configuration changed by the
user - then this is fine and we don't have a problem.

> 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.

The problem here is that the TUI is not aware of vdsm. That's why I
suggest that VDSM is publishing these informations through e.g. the
mechanism which is mentioned in [0] or also maybe through
http://wiki.ovirt.org/Features/Node/FeaturePublishing

Greetings
fabian

> > 
> > 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
> >