[09:50] <amansi26> for cleaning /etc/resolv.conf for sles we deleting symlink of /etc/resolv.conf . Is there any similar thing done for RHEL also. how are we cleaning old /etc/resolv.conf and generating new one? is it done by cloud init or NetworkManager package?
[10:34] <amansi26> I checked the code under rhel_utils.py We are just appending the new dns server, not cleaning the old one. Is there any other place we are cleaning it?
[13:46] <Odd_Bloke> amansi26: There's cc_resolv_conf; I've never had to look at it, so I don't really know the details of what it does.
[13:57] <amansi26> Odd_Bloke: resolv_conf file seems like to make it work, we need to pass dns details under cloud.cfg .I am not sure it will still clear old data or not. But if we don't use it under cloud.cfg  and passing the dns details with Config Drive itself. Ideally it should update the file with latest dns details
[14:05] <Odd_Bloke> amansi26: I'm not sure I follow the use case/issue here.  Could you elaborate a little?
[14:22] <amansi26> Odd_Bloke: I have a image with 2 dns details under /etc/resolv.conf When I try to deploy with 2 new dns, the deployed system retains the old 2 dns value under /etc/resolv.conf and append one of the new dns passed. the old didn't get added with log message "ignoring nameserver 'x.x.x.x': adding would exceed the maximum of '3' name servers (see resolv.conf(5))"
[14:22] <amansi26> I see this on RHEL
[14:22] <amansi26> I understand we can have max of 3 dns in /etc/resolv.conf . but previous/old dns must be cleaned
[14:24] <amansi26> I am passing the dns data with ConfigDrive. datasource use is DataSourceConfigDrive . I am not using resolv_conf module in cloud.cfg
[14:24] <amansi26> Odd_Bloke: ^^
[14:29] <Odd_Bloke> amansi26: "one of the new dns passed" <-- how are you passing these?
[14:29] <Odd_Bloke> In network configuration, or in user-data?
[14:29] <Odd_Bloke> (Can you paste whatever config you're using?)
[15:21] <amansi26> Odd_Bloke: the details are passed as: https://bit.ly/36M4N2i
[15:41] <meena> that's he second worst pastebin I've seen all day
[16:16] <Odd_Bloke> amansi26: Why are there already NetworkManager generated entries in resolv.conf on a first boot?
[16:19] <amansi26> Odd_Bloke: Yeah, might be when I installed a fresh RHEL OS at that time this details got added. I am really not sure how that networkmanager message prompt in /etc/resolv.conf
[16:25] <Odd_Bloke> amansi26: You're installing Red Hat from an ISO rather than using a cloud image?
[16:30] <amansi26> Odd_Bloke: Correct I am using ISO for installation
[16:37] <Odd_Bloke> amansi26: OK, I'm not surprised you're hitting issues: cloud-init is generally intended for use in images that have been prepared for use in clouds (or from images captured from instances launched from such images).  This may not be possible for you, of course, but if you're able to move to using the QCOW2 images which (I think) Red Hat provide, then you'll likely run into fewer issues like this.
[16:39] <amansi26> Odd_Bloke: Sure I will try that. Thanks for suggestion
[16:39] <Odd_Bloke> In this specific case, I believe cloud-init is assuming that you have configured those DNS servers in your image for a reason, and so is not removing them.  It looks like this has been the behaviour since ~2013, so I don't know that it's something we would want to change for this unusual use case.
[16:41] <Odd_Bloke> Given that you _haven't_ configured them for a reason, then I would just remove resolv.conf during your image mastering process, so cloud-init doesn't use the existing entries.  (Though the QCOW2 should already be in this state, so I would still recommend using that if possible. :)