Bug 1450521
| Summary: | Cloud-init fails to set hostname on RHEL 7.3/7.4 VM deployed using template | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | vaibhav <vpagar> | ||||||||||
| Component: | cloud-init | Assignee: | Ryan McCabe <rmccabe> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Vladimir <vshypygu> | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 7.3 | CC: | achareka, aherr, alejandro.cortina2, anazmy, aperotti, boeroboy, dornelas, dscott, fdelorey, fdinitto, gangadhar01a, ipinto, ldelouw, matt, mavital, rmccabe, rvdwees, sbonnevi, spower, vshypygu, xiachen | ||||||||||
| Target Milestone: | rc | Keywords: | Regression, Triaged | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | cloud-init-0.7.9-18.el7 | Doc Type: | If docs needed, set a value | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2018-04-10 14:05:07 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
+1 - Had another customer see this issue using CloudForms w/ RHEL 7.3 template provisioning to RHV. Cloud-init version is cloud-init-0.7.9-3.el7.x86_64. Confirmed that downgrading to 0.7.6 fixed the issue. The workaround was to hard-code 'hostnamectl set-hostname hostname.mydomain.com' into the runcmd section of cloud-init, because that part appears to run after dbus is started. This assumes that the cloud-init template will be ONLY used for RHEL7 and is not being used with other flavors of OS that may not use hostnamectl. also affecting rhel-7.4 latest here is another workaround: https://bugs.launchpad.net/cloud-init/+bug/1662542 ``` # Deactive Default dependencies sed -i '/^\[Unit\]$/,/^\[/ s/^DefaultDependencies=no/#DefaultDependencies=no/' /usr/lib/systemd/system/cloud-init.service sed -i '/^\[Unit\]$/,/^\[/ s/^DefaultDependencies=no/#DefaultDependencies=no/' /usr/lib/systemd/system/cloud-init-local.service # Remove ordering for sysinit.target sed -i '/^\[Unit\]$/,/^\[/ s/^Before=sysinit.target/#Before=sysinit.target/' /usr/lib/systemd/system/cloud-init.service sed -i '/^\[Unit\]$/,/^\[/ s/^Before=sysinit.target/#Before=sysinit.target/' /usr/lib/systemd/system/cloud-init-local.service # order with systemd-hostnamed.service sed -i '/^\[Unit\]$/,/^\[/ s/^After=networking.service/After=networking.service\nAfter=systemd-hostnamed.service/' /usr/lib/systemd/system/cloud-init.service ``` Red Hat Training is also seeing this issue as we work on the next update of our RHV training course. We would love to see a fix here before we release the course, otherwise we're going to have to carry information about the regression and the work around in the course. We also confirm that downgrading from 0.7.9 to 0.7.6 works around the issue. *** Bug 1478708 has been marked as a duplicate of this bug. *** Hi, Ryan I've checked with 0.7.9-16test version and it doesn't update hostname Created attachment 1353409 [details]
log for cloud_init_0.7.9-16test
(In reply to Vladimir from comment #19) > Created attachment 1353409 [details] > log for cloud_init_0.7.9-16test Would it be possible to provide the full output of the boot process? Created attachment 1353586 [details] /var/log for cloud-init-0.7.9-16test Here is the whole /var/log folder Or you can check this VM on the https://compute-ge-9.scl.lab.tlv.redhat.com/ovirt-engine/webadmin/?locale=en_US#vms VM name is cloud_init_test (In reply to Vladimir from comment #26) > Yes, this one works fine, hostname is set successfully checked with: cloud-init-0.7.9-18.el7 moving to verify Guys this is 9 months old. Seriously? (In reply to John Boero from comment #29) > Guys this is 9 months old. Seriously? It's been fixed for months. If you need a package with a fix sooner than the RHEL 7.5 GA, please go through the regular support channels and let them know you need a z-stream. If you're not a customer, I can post attach the patch here, but there's only so much engineering can do without somebody asking. Created attachment 1392233 [details]
fix for the startup ordering
Thanks for clarifying. I don't see the cloud-init-0.7.9-18.el7 release anywhere (apparently as you said it's in EL Z). This is also a current issue in Fedora 27 and even Rawhide (see below). Any chance we can include Fedora and Fedora Atomic? Thanks fedora27 ~ sudo dnf info cloud-init Last metadata expiration check: 2:31:32 ago on Tue 06 Feb 2018 03:13:37 PM UTC. Installed Packages Name : cloud-init Version : 0.7.9 Release : 9.fc27 Arch : noarch Size : 2.0 M Source : cloud-init-0.7.9-9.fc27.src.rpm Repo : @System From repo : anaconda Summary : Cloud instance init scripts URL : http://launchpad.net/cloud-init License : GPLv3 Description : Cloud-init is a set of init scripts for cloud instances. Cloud instances : need special scripts to run during initialization to retrieve and install : ssh keys and to let the user run various scripts. fedora27 ~ sudo dnf --releasever=rawhide info cloud-init Last metadata expiration check: 8 days, 5:58:20 ago on Mon 29 Jan 2018 11:44:03 AM UTC. Installed Packages Name : cloud-init Version : 0.7.9 Release : 9.fc27 Arch : noarch Size : 2.0 M Source : cloud-init-0.7.9-9.fc27.src.rpm Repo : @System From repo : anaconda Summary : Cloud instance init scripts URL : http://launchpad.net/cloud-init License : GPLv3 Description : Cloud-init is a set of init scripts for cloud instances. Cloud instances : need special scripts to run during initialization to retrieve and install : ssh keys and to let the user run various scripts. Available Packages Name : cloud-init Version : 17.1 Release : 1.fc28 Arch : noarch Size : 823 k Source : cloud-init-17.1-1.fc28.src.rpm Repo : updates Summary : Cloud instance init scripts URL : http://launchpad.net/cloud-init License : ASL 2.0 or GPLv3 Description : Cloud-init is a set of init scripts for cloud instances. Cloud instances : need special scripts to run during initialization to retrieve and install : ssh keys and to let the user run various scripts. Yes I have a subscription and access to Z-Stream repos but surprised it's not GA yet and surprised it's not hit Fedora yet. Sure, I can work with the Fedora maintainer to get it fixed there. The build mentioned in the comments was an interim build that was only tested internally. In general, we're only able to release a package with a fix between releases in RHEL if there's an associated customer who asks for a package with a fix sooner, and that request is approved -- it's kind out of our hands. For Fedora, there's a lot less process involved, and getting a fix out shouldn't take long at all. Could you please file a bug against the Fedora package? You can clone this bug against the Fedora releases that are broken to save time. OK excellent thanks Ryan. I'll file that now. Hi, I am having the same issue for CentOS 7 VM, any fix for this? Created attachment 1417331 [details]
patch
Yes, the fix will be in the next release. I have attached the patch that fixes it if you don't want to wait.
I have noticed the RHEV not using the cloud init pay load for CentOS machines VM. We are using the following version cloud-init.x86_64 0.7.9-9.el7 I will provide an update after I applied the patch. Hopefully this should work. 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. https://access.redhat.com/errata/RHEA-2018:0806 *** Bug 1542657 has been marked as a duplicate of this bug. *** |
Description of problem: Cloud-init can not set hostname for the RHEL 7.3 VM deployed using template. Version-Release number of selected component (if applicable): RHEL 7.3 cloud-init-0.7.9-3.el7.x86_64 How reproducible: Steps to Reproduce: 1. Create template of RHEL 7.3 which includes cloud-init package 2. Deploy new VM using template and try to set hostname using cloud-init 3. Check hostname after successfully deploying VM. Actual results: Hostname is not changing using cloud-init Expected results: Hostname should change when using cloud-init for initial setup. Additional info: Reproduced issue and getting below traceback error :- ~~~~~~~~~~~~~~ 2017-05-13 02:22:46,834 - helpers.py[DEBUG]: Running config-set_hostname using lock (<FileLock using file '/var/lib/cloud/instances/131558a1-38bb-41f6-bb78-46e6a5e4c307/sem/config_set_hostname'>) 2017-05-13 02:22:46,834 - cc_set_hostname.py[DEBUG]: Setting the hostname to vpagar.localhost.com (vpagar) 2017-05-13 02:22:46,834 - util.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'vpagar.localhost.com'] with allowed return codes [0] (shell=False, capture=True) 2017-05-13 02:22:46,840 - util.py[WARNING]: Failed to set the hostname to vpagar.localhost.com (vpagar) 2017-05-13 02:22:46,840 - util.py[DEBUG]: Failed to set the hostname to vpagar.localhost.com (vpagar) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloudinit/config/cc_set_hostname.py", line 47, in handle cloud.distro.set_hostname(hostname, fqdn) File "/usr/lib/python2.7/site-packages/cloudinit/distros/__init__.py", line 84, in set_hostname self._write_hostname(writeable_hostname, self.hostname_conf_fn) File "/usr/lib/python2.7/site-packages/cloudinit/distros/rhel.py", line 130, in _write_hostname util.subp(['hostnamectl', 'set-hostname', str(hostname)]) File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 1850, in subp cmd=args) ProcessExecutionError: Unexpected error while running command. Command: ['hostnamectl', 'set-hostname', 'vpagar.localhost.com'] Exit code: 1 Reason: - Stdout: - Stderr: Failed to create bus connection: No such file or directory 2017-05-13 02:22:46,844 - handlers.py[DEBUG]: finish: init-local/config-set_hostname: FAIL: running config-set_hostname with frequency once-per-instance ~~~~~~~~~~~~~~