| === dbungert1 is now known as dbungert | ||
| === cpaelzer_ is now known as cpaelzer | ||
| holmanb | minimal: did you have any concerns around changing the failure path in this case: datasource_list: [OpenStack, None] | 14:29 |
|---|---|---|
| holmanb | minimal: regarding no "None" fallback? | 14:30 |
| holmanb | minimal: looks like this has enough reviews to be merged | 14:35 |
| holmanb | *more than enough | 14:35 |
| holmanb | meena: good question regarding get_proc_env(1) | 14:43 |
| holmanb | meena: also sorry for the churn on is_virtual :/ | 14:44 |
| 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:24 |
| holmanb | minimal: I looks normal to me (firefox) | 15:27 |
| minimal | holmanb: doh! user error, was looking at "canonical/cloud-init/cloudinit/" rather than "canonical/cloud-init" | 15:28 |
| 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:29 |
| minimal | s/to be/to me/ | 15:30 |
| holmanb | +1 minimal: gotcha. It should behave the same both ways. | 15:37 |
| 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? | 15:44 |
| holmanb | minimal: It will still get to DataSourceNone, just after trying DataSourceOpenStack | 16:06 |
| holmanb | minimal: logs of this -> https://dpaste.org/BHGK3 | 16:08 |
| minimal | ok | 16:29 |
| 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:33 |
| esv | my question is why?? or how? , the adapter name remains as eth0 | 19:34 |
| holmanb | esv: dhclient is managed/executed by cloud-init itself, outself of your distro's network manager | 19:43 |
| holmanb | esv - cloud-init will doesn't read your ifcfg-eth0 file, so any changes (or lack thereof) are ignored | 19:44 |
| 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:19 |
| 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:20 |
| 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:33 |
| holmanb | dhclient execution is defined here -> https://github.com/canonical/cloud-init/blob/d1ffbea556a06105d1ade88b4143ad43f53692c4/cloudinit/net/dhcp.py#L139 | 20:35 |
| 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 | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!