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.
What is the net effect of having the systems using the same machine-id?
Derek, is this a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1244328 or related to the fix for that bug?
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.
clearing needinfo
Please confirm that just removing this file from the image would actually work. Or should we better regenerate it?
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.
Any update for it ? Does this issue will be fixed in release 8 ?
Still valid on OSP8...
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.
First patch posted
Second patch posted. Waiting for reviews now (it can also take substantial time).
Can you link your patch here ?
Please see External Trackers section on this bug (before the comments).
(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.
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.
(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.
So it doesn't get called automatically, does it? Then I misunderstood this issue a bit..
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.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
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.
Oh I'm sorry little bug ... I forgot you ... I missed your birthday .. Happy Birthday bug ! More seriously, anyone to take care of it ?!?
Updating BZ to reflect partner desire for this fix.
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.
(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...
Ben - What's the next step for this? How do we get some movement towards resolving it?
Ack, LGTM
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.
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.
Will this be back ported to OSP 10?
Bug 1476612 is for OSP10
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
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-2017:3462