----- Original Message ----- > From: "Fabian Deutsch" <[email protected]> > To: "arch" <[email protected]>, "node-devel" <[email protected]> > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/node-devel > _______________________________________________ node-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/node-devel
