Bug 1476612 - /etc/machine-id is the same on all overcloud nodes (well the base RHEL 7.x image)
/etc/machine-id is the same on all overcloud nodes (well the base RHEL 7.x i...
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-puppet-elements (Show other bugs)
10.0 (Newton)
Unspecified Unspecified
medium Severity medium
: ---
: 10.0 (Newton)
Assigned To: Alex Schultz
Gurenko Alex
: TestOnly, Triaged, ZStream
Depends On: 1481443 1270860
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-30 14:10 EDT by David Hill
Modified: 2017-12-13 11:48 EST (History)
9 users (show)

See Also:
Fixed In Version: openstack-tripleo-puppet-elements-5.3.2-1.el7ost openstack-tripleo-common-5.4.4-1.el7ost rhosp-director-images-10.0-20171108.1.el7ost
Doc Type: Bug Fix
Doc Text:
Cause: The overcloud images provided and built using diskimage-builder included a static /etc/machine-id which was not automatically generated when nodes booted. Consequence: The /etc/machine-id would be identical on all overcloud nodes which can cause issues with other software. Fix: The /etc/machine-id is now cleared when images are built and the provided overcloud-full image has an empty /etc/machine-id. Result: The /etc/machine-id will be generated on initial boot when new nodes are added to the deployment or new deployments are created. Known Issue: Any existing nodes that were deployed with the previous images may have the same machine-id and will not be updated. If you need a unique machine-id, you can truncate the /etc/machine-id and reboot to have systemd generate a new one. NOTE: If you want to do this, do not remove /etc/machine-id as systemd will only generate an id if the file exists. The correct way to reset it is to have an empty /etc/machine-id and reboot.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-13 11:48:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1707526 None None None 2017-07-30 14:29 EDT
OpenStack gerrit 445173 None None None 2017-08-06 18:34 EDT
OpenStack gerrit 445174 None None None 2017-08-06 18:34 EDT
OpenStack gerrit 489013 None None None 2017-08-06 18:30 EDT
OpenStack gerrit 505305 None None None 2017-09-19 15:52 EDT
OpenStack gerrit 505310 None None None 2017-09-19 15:53 EDT
OpenStack gerrit 507561 None None None 2017-11-09 14:34 EST

  None (edit)
Description David Hill 2017-07-30 14:10:43 EDT
Description of problem:
/etc/machine-id is the same on all overcloud nodes  (well the base RHEL 7.x image) so in a case where we're validating /etc/machine-id to be unique, it would create a conflict and only one node could be added (RHCS let's say).   I'm hesitating between creating a BZ for cloud-init or heat-templates to adress this. 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Deploy an overcloud
2.
3.

Actual results:
They all have the same /etc/machine-id value

Expected results:
Should be different somehow

Additional info:
Comment 1 David Hill 2017-07-30 14:20:59 EDT
(undercloud) [stack@undercloud-0-trunk ~]$ cat /etc/machine-id 
c9b62f7bee8b444da86ee1bc26aa7e72
(undercloud) [stack@undercloud-0-trunk ~]$ ssh heat-admin@192.0.2.9
The authenticity of host '192.0.2.9 (192.0.2.9)' can't be established.
ECDSA key fingerprint is d8:29:01:55:ef:7e:c7:29:08:d2:c0:fa:7e:28:9f:28.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.0.2.9' (ECDSA) to the list of known hosts.
[heat-admin@overcloud-controller-0 ~]$ cat /etc/machine-id 
c9b62f7bee8b444da86ee1bc26aa7e72



This could also be fixed in the image builder tool by deleting that file and creating it if it's missing on first boot.
Comment 2 Alex Schultz 2017-07-31 09:05:36 EDT
This was fixed in Ocata as part of Bug 1270860. We would need to backport the appropriate changes.
Comment 3 David Hill 2017-07-31 09:27:36 EDT
Is it fixed?  I clicked one of the openstack gerrit and the changes were abandonned.  Also , deleting it will prevent the system from starting properly but setting it as an empty file should work.
Comment 4 Alex Schultz 2017-07-31 11:26:33 EDT
Correct, the two abandoned reviews were for fixes to DIB which were rejected. The first to listed on that bug were merged which were tripleo specific fixes for this issue. It's not a problem from 11+. We would have to backport for 10 and make sure images are rebuilt for 10.

https://review.openstack.org/#/c/445174/
https://review.openstack.org/#/c/445173/
Comment 5 Alex Schultz 2017-07-31 14:08:59 EDT
Well I just verified that the file is still there. So I guess it needs further investigation.
Comment 6 David Hill 2017-08-06 18:29:57 EDT
In 11, it'll be a problem if we only do a "rm -rf /etc/machine-id"... we must recreate it afterwards with "touch /etc/machine-id" !   We can probably abandon my change if we take this one.
Comment 7 David Hill 2017-08-06 18:30:42 EDT
https://review.openstack.org/#/c/489013/
Comment 9 David Hill 2017-08-06 18:35:46 EDT
Let me test this in Ocata and confirm if it's removing /etc/machine-id
Comment 10 Alex Schultz 2017-08-07 11:46:36 EDT
So we'll fix this for tripleo via a backport of the previously mentioned items. https://review.openstack.org/#/c/489618/ is required to make it work for tripleo at the moment. We won't backport any work for disk image builder if that gets merged.
Comment 11 Lon Hohberger 2017-11-16 16:05:33 EST
According to our records, this should be resolved by openstack-tripleo-puppet-elements-5.3.2-1.el7ost.  This build is available now.
Comment 12 Lon Hohberger 2017-11-16 16:05:39 EST
According to our records, this should be resolved by openstack-tripleo-common-5.4.4-1.el7ost.  This build is available now.
Comment 13 Lon Hohberger 2017-11-16 16:05:45 EST
According to our records, this should be resolved by rhosp-director-images-10.0-20171108.1.el7ost.  This build is available now.
Comment 14 Gurenko Alex 2017-12-13 06:17:41 EST
Verified on build 2017-12-05.1 with RHEL 7.4 and rhosp-director-images-10.0-20171204.1.el7ost

Note You need to log in before you can comment on or make changes to this bug.