RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1048932 - Shared configuration keys to pass management informations
Summary: Shared configuration keys to pass management informations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.5
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Fabian Deutsch
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1021647 1048929
Blocks: 1006338 1006838 1017173
TreeView+ depends on / blocked
 
Reported: 2014-01-06 14:32 UTC by Fabian Deutsch
Modified: 2014-01-21 19:41 UTC (History)
19 users (show)

Fixed In Version: ovirt-node-3.0.1-14.el6
Doc Type: Bug Fix
Doc Text:
When a Node is being managed by, for example, by oVirt Engine, it should prevent the user from changing certain elements such as the Network configuration, as the network configuration is done by Engine/VDSM. Keys have been added to let the TUI know about: - The management instance which is managing Node - Important NICs on the system - Pages to be locked These changes help with Node management.
Clone Of: 1021647
Environment:
Last Closed: 2014-01-21 19:41:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0033 0 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2014-01-22 00:14:30 UTC
oVirt gerrit 22374 0 None None None Never

Description Fabian Deutsch 2014-01-06 14:32:41 UTC 
+++ This bug was initially created as a clone of Bug #1021647 +++

Description of problem:
When Node is beeing managed by e.g. oVirt Engine it should prevent the user from change e.g. the Network configuration as the network configuration is done by Engine/VDSM.

Additionally it might make sense if the management instance told Node's TUI what interface the primary interface is so the TUI can display live informations about the NICs.

I'm suggesting the following keys which are shared by Node and the management instance to exchange relevant bits:

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

--- Additional comment from Fabian Deutsch on 2013-11-28 13:25:14 CET ---

Douglas,

currently the ovirt node tui can only display reliable network informations when the network got configured by the tui. When vdsm is taking over the network configuration the tui displays incorrect informations (on the status page).

To improve the situation we need to sync the network informations (and maybe others) between the tui and vdsm. My suggestion is to use some keys which vdsm can use to tell the tui about the e.g. primary NIC (some brige, ovs ...) to display a summary about.

--- Additional comment from Douglas Schilling Landgraf on 2013-11-28 14:08:12 CET ---

Hi Fabian,

Make sense. However, for this specific network point, better include vdsm network folks into this thread.

--- Additional comment from Dan Kenigsberg on 2013-11-28 16:31:15 CET ---

I've stated my opinion in http://lists.ovirt.org/pipermail/arch/2013-October/001688.html

I see the merit of locking network tui after registration (provided that there's a means to unlock it), but not much of the rest.
Comment 4 Charlie 2014-01-13 01:42:53 UTC 
Hi, not sure what was fixed here for the errata text, could you please give me an explanation of what the problem was and what was done? Thanks.
Comment 10 errata-xmlrpc 2014-01-21 19:41:22 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0033.html
Note You need to log in before you can comment on or make changes to this bug.