Bug 1270860 - All nodes are sharing the same machine-id
All nodes are sharing the same machine-id
Status: VERIFIED
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-puppet-elements (Show other bugs)
7.0 (Kilo)
All Linux
urgent Severity urgent
: beta
: 12.0 (Pike)
Assigned To: Alex Schultz
Gurenko Alex
: Triaged
Depends On:
Blocks: 1401639 1476612 1481443
  Show dependency treegraph
 
Reported: 2015-10-12 10:29 EDT by Erwan Velu
Modified: 2017-11-07 07:40 EST (History)
32 users (show)

See Also:
Fixed In Version: openstack-tripleo-puppet-elements-7.0.0-0.20170819032135.23884d3.el7ost openstack-tripleo-common-7.4.1-0.20170818153039.7d74e83.el7ost
Doc Type: Bug Fix
Doc Text:
.Storage nodes showing identical machine IDs Using hardcoded machine IDs in templates creates multiple nodes with identical machine IDs. As a consequence, Red Hat Storage Console fails to recognize multiple nodes as the machine IDs are identical. As a workaround, generate unique machine IDs on each node and update the /etc/machine-id file. This will ensure Storage Console to identify the nodes as unique.Ac
Story Points: ---
Clone Of:
: 1481443 (view as bug list)
Environment:
Last Closed:
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 1672461 None None None 2017-03-13 13:20 EDT
OpenStack gerrit 445173 None None None 2017-03-13 16:45 EDT
OpenStack gerrit 445174 None None None 2017-03-13 16:45 EDT
OpenStack gerrit 489618 None None None 2017-08-01 10:24 EDT

  None (edit)
Description Erwan Velu 2015-10-12 10:29:01 EDT
Description of problem:
All nodes deployed using directord are sharing the same /etc/machine-id which is supposed to be unique.


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


How reproducible:
Install a cloud and watch /etc/machine-id on all nodes.
That's exactly the same everywhere

Steps to Reproduce:
1.
2.
3.

Actual results:
All nodes are sharing the same /etc/machine-id

Expected results:
Shall be different on all nodes

Additional info:
Sounds like the machine-id is inside the golden image making all node sharing the same one.
Comment 2 chris alfonso 2015-10-12 12:07:04 EDT
What is the net effect of having the systems using the same machine-id?
Comment 3 chris alfonso 2015-10-12 12:07:04 EDT
What is the net effect of having the systems using the same machine-id?
Comment 9 Hugh Brock 2016-02-05 06:20:27 EST
Derek, is this a dup of  https://bugzilla.redhat.com/show_bug.cgi?id=1244328 or related to the fix for that bug?
Comment 10 Derek Higgins 2016-02-05 08:05:19 EST
Both bugs have similar causes, a unique identifier is being generated during the image build and then being used on all machines its deployed to. But they need to be tracked separately as the fixes for them wont be the same.
Comment 11 James Slagle 2016-02-17 12:09:29 EST
clearing needinfo
Comment 15 Dmitry Tantsur 2016-02-19 07:21:34 EST
Please confirm that just removing this file from the image would actually work. Or should we better regenerate it?
Comment 16 Erwan Velu 2016-02-19 08:57:15 EST
For the new systems yes, deleting the file from the image is enough as systemd will generate it at boot time.

The question is about the systems already setup with this one ... shall we keep it ? Shall we delete it and regenerate ? I don't know the impacts and the products using that number like satelite.
Comment 17 Erwan Velu 2016-03-29 05:25:28 EDT
Any update for it ? Does this issue will be fixed in release 8 ?
Comment 18 Erwan Velu 2016-04-05 03:58:38 EDT
Still valid on OSP8...
Comment 19 Dmitry Tantsur 2016-04-05 06:29:41 EDT
Thanks for reminder, I think I have some time to look into it.

I'm making this bug public, as I don't see anything private about it, and it's good to be able to reference our bugs upstream.
Comment 20 Dmitry Tantsur 2016-04-05 06:46:26 EDT
First patch posted
Comment 21 Dmitry Tantsur 2016-04-05 06:55:21 EDT
Second patch posted. Waiting for reviews now (it can also take substantial time).
Comment 22 Erwan Velu 2016-04-05 09:16:56 EDT
Can you link your patch here ?
Comment 23 Dmitry Tantsur 2016-04-05 09:31:49 EDT
Please see External Trackers section on this bug (before the comments).
Comment 24 Erwan Velu 2016-04-05 10:17:23 EDT
(In reply to Dmitry Tantsur from comment #23)
> Please see External Trackers section on this bug (before the comments).

Thx I didn't noticed it before.
Would have been nice being mentioned in the commit message. Anyway, good to see it's on the way.
Comment 25 Dmitry Tantsur 2016-04-05 10:27:28 EDT
It seems like systemd does not even bother starting IPA when machine-id is missing. I'm not sure why, but for now I'll get back to only removing machine-id for overcloud-full.
Comment 26 Erwan Velu 2016-04-05 11:33:55 EDT
(In reply to Dmitry Tantsur from comment #25)
> It seems like systemd does not even bother starting IPA when machine-id is
> missing. I'm not sure why, but for now I'll get back to only removing
> machine-id for overcloud-full.

You may need to call systemd-machine-id-setup at some time.
Comment 27 Dmitry Tantsur 2016-04-05 11:42:05 EDT
So it doesn't get called automatically, does it? Then I misunderstood this issue a bit..
Comment 28 Erwan Velu 2016-04-05 12:11:40 EDT
It seems that the installer should do some tasks around it so maybe the osp installer too.

Note that I'm not a deep systemd expert.
Comment 29 Mike Burns 2016-04-07 16:54:03 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 33 Dmitry Tantsur 2016-08-09 12:44:05 EDT
Sorry, I have to unassign myself. The patch upstream has caused a long discussion about support for various distros and how to recreate this file on boot properly. I don't have any time to continue working on it. Anyone is free to overtake the abandoned patches.
Comment 34 Erwan Velu 2016-10-18 14:55:43 EDT
Oh I'm sorry little bug ... I forgot you ...

I missed your birthday .. Happy Birthday bug !

More seriously, anyone to take care of it ?!?
Comment 35 Sean Merrow 2017-01-19 13:12:20 EST
Updating BZ to reflect partner desire for this fix.
Comment 36 Alan Bishop 2017-01-19 16:19:42 EST
What are the downsides (if there are any) to generating new machine IDs on the overcloud nodes? Apparently the Storage Console requires they be unique, and so I need to know if anything else will break or complain if the IDs change. So far I haven't noticed any breakage or SELinux issues, but I'd like a definitive answer.
Comment 37 Erwan Velu 2017-01-20 04:01:19 EST
(In reply to Alan Bishop from comment #36)
> What are the downsides (if there are any) to generating new machine IDs on
> the overcloud nodes? Apparently the Storage Console requires they be unique,
> and so I need to know if anything else will break or complain if the IDs
> change. So far I haven't noticed any breakage or SELinux issues, but I'd
> like a definitive answer.

I don't see any downside .... Systemd will re-generate it...
Comment 40 Ian Colle 2017-01-30 11:29:08 EST
Ben - What's the next step for this? How do we get some movement towards resolving it?
Comment 43 Nishanth Thomas 2017-01-31 05:17:32 EST
Ack, LGTM
Comment 47 Red Hat Bugzilla Rules Engine 2017-02-13 09:20:38 EST
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.
Comment 55 Alex Schultz 2017-07-03 15:48:04 EDT
Those changes were superseded by the subsequent changes https://review.openstack.org/445173 and https://review.openstack.org/445174 which were targeted to tripleo only.  The previous ones were pushed against DIB and the upstream seemed to not want to do that.  I didn't want to drop them from the bug as to not lose some of the history.
Comment 58 Randy Perryman 2017-09-18 12:15:08 EDT
Will this be back ported to OSP 10?
Comment 59 Alex Schultz 2017-09-19 15:51:34 EDT
Bug 1476612 is for OSP10
Comment 61 Artem Hrechanychenko 2017-11-07 07:40:43 EST
Verified:


openstack-tripleo-puppet-elements-7.0.1-0.20171020122223.82d7e6c.el7ost.noarch
openstack-tripleo-common-7.6.3-0.20171028055750.el7ost.noarch


(undercloud) [stack@undercloud-0 ~]$ for i in `openstack server list -f value -c Networks |awk -F'=' '{print $2}'`; do echo "############################################"; ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname; sudo cat /etc/machine-id"; done
############################################
controller-3
e3f151e9c436443b844d1346c213e959
############################################
controller-2
94d12be698ab4441b900677170aa1aa3
############################################
controller-0
aeeedae034684f61af5857a16a77b185
############################################
controller-1
f74fe0c617b9479fa8fbad427a16c97c
############################################
compute-0
e8a89b2eb3c043cdba08b36d7d51629a

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