Bug 1476612 - /etc/machine-id is the same on all overcloud nodes (well the base RHEL 7.x image)
Summary: /etc/machine-id is the same on all overcloud nodes (well the base RHEL 7.x i...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-puppet-elements
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 10.0 (Newton)
Assignee: Alex Schultz
QA Contact: Gurenko Alex
URL:
Whiteboard:
Depends On: 1270860 1481443
Blocks: 1551603 1555474 1557046
TreeView+ depends on / blocked
 
Reported: 2017-07-30 18:10 UTC by David Hill
Modified: 2020-12-14 09:16 UTC (History)
10 users (show)

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.
Clone Of:
: 1551603 (view as bug list)
Environment:
Last Closed: 2017-12-13 16:48:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1707526 0 None None None 2017-07-30 18:29:17 UTC
OpenStack gerrit 445173 0 None MERGED Add remove-machine-id element 2021-02-14 10:40:02 UTC
OpenStack gerrit 445174 0 None MERGED Remove machine-id from image 2021-02-14 10:40:02 UTC
OpenStack gerrit 489013 0 None MERGED Clear /etc/machine-id to avoid duplicate machine-ids 2021-02-14 10:40:02 UTC
OpenStack gerrit 505305 0 None MERGED Add remove-machine-id element 2021-02-14 10:40:02 UTC
OpenStack gerrit 505310 0 None MERGED Remove machine-id from image 2021-02-14 10:40:02 UTC
OpenStack gerrit 507561 0 None MERGED Set remove-machine-id to executable 2021-02-14 10:40:02 UTC

Description David Hill 2017-07-30 18:10:43 UTC
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 18:20:59 UTC
(undercloud) [stack@undercloud-0-trunk ~]$ cat /etc/machine-id 
c9b62f7bee8b444da86ee1bc26aa7e72
(undercloud) [stack@undercloud-0-trunk ~]$ ssh heat-admin.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 13:05:36 UTC
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 13:27:36 UTC
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 15:26:33 UTC
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 18:08:59 UTC
Well I just verified that the file is still there. So I guess it needs further investigation.

Comment 6 David Hill 2017-08-06 22:29:57 UTC
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 22:30:42 UTC
https://review.openstack.org/#/c/489013/

Comment 9 David Hill 2017-08-06 22:35:46 UTC
Let me test this in Ocata and confirm if it's removing /etc/machine-id

Comment 10 Alex Schultz 2017-08-07 15:46:36 UTC
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 21:05:33 UTC
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 21:05:39 UTC
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 21:05:45 UTC
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 11:17:41 UTC
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.