Am Sonntag, den 27.10.2013, 06:58 -0400 schrieb Moti Asayag: > > ----- 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 ?
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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/node-devel > > _______________________________________________ node-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/node-devel
