=== dbungert1 is now known as dbungert
=== cpaelzer_ is now known as cpaelzer
[14:29] <holmanb> minimal: did you have any concerns around changing the failure path in this case: datasource_list: [OpenStack, None]
[14:30] <holmanb> minimal: regarding no "None" fallback?
[14:35] <holmanb> minimal: looks like this has enough reviews to be merged
[14:35] <holmanb> *more than enough
[14:43] <holmanb> meena: good question regarding get_proc_env(1)
[14:44] <holmanb> meena: also sorry for the churn on is_virtual :/
[15:24] <minimal> have github changed the way repos look? just went to cloud-init page and the usual stuff that used to appear down the right-hand side such as License, Releases, etc is not there any more
[15:27] <holmanb> minimal: I looks normal to me (firefox)
[15:28] <minimal> holmanb: doh! user error, was looking at "canonical/cloud-init/cloudinit/" rather than "canonical/cloud-init"
[15:29] <minimal> holmanb: re the Openstack-related PR it wasn't clear to be if a DS list of ["Openstack"] was going to be treated in the same way or differently to ["OpenStack","None]
[15:30] <minimal> s/to be/to me/
[15:37] <holmanb> +1 minimal: gotcha. It should behave the same both ways.
[15:44] <minimal> holmanb: the change in sources/__init__.py, the new function "override_ds_detect treats ['XYZ'] and ['XYZ', 'None'] as being an override? whereas currently ['XYZ', 'None'] means that if XYZ cannot be used then None is used, i.e. with ['NoCloud', 'None'] currently if no "CIDATA" is provided then it will fallback to 'None' and use DHCP - with this change in place what happens in that scenario?
[16:06] <holmanb> minimal: It will still get to DataSourceNone, just after trying DataSourceOpenStack
[16:08] <holmanb> minimal: logs of this -> https://dpaste.org/BHGK3
[16:29] <minimal> ok
[19:33] <esv> hey folks, I am running a rhel7.9 on azure with cloud-init 19.4, I know, I know, it's old as shiii, but that's what I have to work with... my situation is the following, I replace the NIC but the ifcfg-eth0 file does not get regenerated, it keeps the old mac, but the server  still starts the new adapter as eth0 and uses it as a dhcp client.
[19:34] <esv> my question is why?? or how? , the adapter name remains as eth0
[19:43] <holmanb> esv: dhclient is managed/executed by cloud-init itself, outself of your distro's network manager
[19:44] <holmanb> esv - cloud-init will doesn't read your ifcfg-eth0 file, so any changes (or lack thereof) are ignored
[20:19] <esv> lol - now I am more confused, I've been involved in many situations where updating the hw in ifcfg-eth0 fixes the issues with the servers not picking the right ip address
[20:19] <esv> does that happen with setup.py ?
[20:20] <esv> in this particular customer situation, they commented out the MAC address of the adapter in ifcfg-eth0 and the server picked the network parameters right away
[20:33] <holmanb> esv: sure, adding the hwaddr in ifcfg-eth0 can help some scenarios in administering a box, but it's not going to affect the dhclient invocation, I don't think
[20:35] <holmanb> dhclient execution is defined here -> https://github.com/canonical/cloud-init/blob/d1ffbea556a06105d1ade88b4143ad43f53692c4/cloudinit/net/dhcp.py#L139
[20:36] <holmanb> however on rhel7 you're talking about a very different codebase - 19.x and python2, so I don't know exactly the scenario you're looking at
[20:36] <esv> thnx