Bug 737722
Summary: | vdsm-reg params are not removed from cmdline after registering to RHEV-M | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Mike Burns <mburns> | ||||||
Component: | vdsm | Assignee: | Yotam Oron <yoron> | ||||||
Status: | CLOSED ERRATA | QA Contact: | yeylon <yeylon> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 6.2 | CC: | abaron, apevec, bazulay, cshao, danken, gouyang, iheim, leiwang, mburns, moli, mprpic, pstehlik, srevivo, ycui, yeylon, ykaul | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | vdsm-4.9-107 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | 723115 | Environment: | |||||||
Last Closed: | 2011-12-06 07:28:30 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 723115 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
Mike Burns
2011-09-12 23:24:00 UTC
Mike, vdsm-reg is taking its needed parameters from vdsm-reg.conf. The values in this file are configured once, either via TUI or kernel params - both on installation. After that, the kernel params are not relevant anymore (at least in the vdsm-reg case). From your description, it seems you might be using the wrong port (or older rhevm ?), which causes the certificate not to be downloaded etc. Please clarify. Created attachment 523088 [details] Proposed patch (In reply to comment #2) > Please clarify. This is to avoid management_server* being propagated to grub config, they are installation-time only parameters so they shouldn't be present on subsequent normal boot from disk. vdsm-config reads /proc/cmdline and changes vdsm-reg.conf on reboot after upgrade, so it might be confusing for users who changed vdsm-reg.conf to see it reverted to the values hidding in cmdline, esp. if there was a typo in the initial value which they wanted to correct. Proposed patch is attached. Is there any reason to haste this into RHEV 3.0 beta 3? If so, please wave the rhel-6.2.0 flag again. (In reply to comment #4) > Is there any reason to haste this into RHEV 3.0 beta 3? I vote for 6.2: patch is simple and low-risk and for justification let's ask original bug submitter Pavel (bug 723115) Created attachment 523623 [details]
suggested upsteam patch
The patch seems harmless, but our typical user is not editing vdsm-reg.conf manually. I'm a bit worried about fixing a low-severity (and very old) bug during beta period.
I attach a version of Alan's patch rebased on upstream Vdsm. I prefer taking it only to there - unless there is a true reason for exception+.
Removed release_notes flag (not needed) Changing prio to HIGH. Seems that this has a very undesired implication. Scenario: - Install a node with kernel params - Change the RHEVM that the node is working with (using the TUI or any other standard way) - Upgrade the node - vdsm-reg is trying to register with the old RHEVM (the IP address is in the command line arguments that now seem to be parsed and processed on upgrade) *** Bug 744511 has been marked as a duplicate of this bug. *** *** Bug 745412 has been marked as a duplicate of this bug. *** verified on vdsm-4.9-108.el6.x86_64 Red Hat Enterprise Virtualization Hypervisor release 6.2 (20111019.2) 1. use an old version of rhev-h kernel params set vdc_host to host A 2. use TUI to change vdc_host to host B 3. register & approve to host B 4. upgrade the node from with in the RHEVM to version 6.2 (20111019.2) 5. check in vdsm-reg.com vdc_host param remains host B same steps as Bug 744511 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/RHEA-2011-1782.html |