| === cpaelzer_ is now known as cpaelzer | ||
| === cpaelzer_ is now known as cpaelzer | ||
| === rharper_ is now known as rharper | ||
| === milosz_ is now known as milosz | ||
| saimsh | Hi all, I am from Azure Linux Escalation Support team and I have a customer who is attempting to implement resolv conf module in custom-data. However, in our endorsed ubuntu 18.04 images,resolv conf is not listed as a module under /etc/cloud/cloud.cfg. Is it ok to manually add it to the config file? and if so, what would be the correct location( | 20:21 |
|---|---|---|
| saimsh | stage) to add it. I am currently testing by adding it under init stage (at the end) | 20:21 |
| saimsh | looking for some valuable insights. any help is appreciated :) | 20:21 |
| falcojr | saimsh: when resolv_conf is enabled, it usually goes under "cloud_init_modules" after "update_etc_hosts". They'll also need to add "resolv_conf" to "unverified_modules" since it's not normally enabled for debian/ubuntu | 20:28 |
| falcojr | this explains why it's not normally enabled | 20:28 |
| falcojr | https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=resolv#resolv-conf | 20:28 |
| saimsh | @falcojr this is very helpful. Thank you very much :) | 20:45 |
| saimsh | just to be sure the unverified | 20:46 |
| saimsh | oops .. hit enter | 20:47 |
| saimsh | just to be sure the unverified_modules: ['resolv conf'] is the correct syntax to be added to /etc/cloud/cloud.cfg ? Also, this module has a space in between resolv and conf. do we need to use the internal name resolv_conf instead? | 20:48 |
| falcojr | saimsh: resolv_conf (with the underscore) | 20:52 |
| saimsh | regarding the location, i believe we can either add it directly to /etc/cloud/cloud.cfg or within a new file in /etc/cloud/cloud.cfg.d correct? | 20:53 |
| falcojr | yes | 20:53 |
| === meena6 is now known as meena | ||
| falcojr | I'm looking at an issue where we're trying to convert a v2 config to something other than netplan | 21:40 |
| falcojr | https://paste.ubuntu.com/p/MVKch3Fx2d/ | 21:40 |
| falcojr | ^ is the debug output from cloud-init devel net-convert | 21:40 |
| falcojr | everything under "config" is the v2 config that was passed | 21:41 |
| falcojr | everything after is our internal network configuration that the renderers are supposed to use to render their respective configs | 21:41 |
| falcojr | but it looks like all of the nameserver info has disappeared completely | 21:42 |
| falcojr | which is somewhat surprising given how long we've had v2 for now | 21:42 |
| falcojr | rharper or smoser , I noticed both of you fairly involved on a possibly related bug (pad.lv/1750884) , is this just a bug? Or is there a reason we're doing things this way? | 21:44 |
| blackboxsw | all I can find/recall is that we used to have v1 config in most places and I know a lot of work&bugs were fixed related to v1 -> v2 network conversion related to handling global DNS in v1 -> device-specific nameservers in v2/netplan. As you said, this might be a bug in v2 -> internal network_state dns because generally on netplan aware systems we just do passthrough v2 -> netplan output, we really look at internal network_state | 22:05 |
| blackboxsw | so trying to map v2 input to internal network_state probably needs tests as well as adding some logic into either NetworkStateInterpreter._v2_common maybe to fix how nameservers are promoted to common internal network_state maybe? | 22:10 |
| blackboxsw | falcojr: FWIW It actually looks like the "command" dict we construct in https://github.com/canonical/cloud-init/blob/master/cloudinit/net/network_state.py#L716 is incorrect because it should be "address" key instead of "addresses" (v1 config is used internally to reprsent network_state) | 22:19 |
| blackboxsw | falcojr: FWIW It actually looks like the "command" dict we construct in https://github.com/canonical/cloud-init/blob/master/cloudinit/net/network_state.py#L716 is incorrect because it should be "address" key instead of "addresses" (v1 config is used internally to represent network_state) | 22:19 |
| blackboxsw | when I look at what is cobbled together in _v2_common vs what handle_nameserver() expects, the keys don't line up | 22:19 |
| blackboxsw | https://github.com/canonical/cloud-init/blob/master/cloudinit/net/network_state.py#L529-L530 here | 22:20 |
| blackboxsw | and since no "address" key is in the dict, we skip_broken=True | 22:20 |
| rharper | no bot here for bug expansion ... man | 22:28 |
| Xe | how do i use cloud-init to run commands before all filesystems are mounted? | 22:28 |
| rharper | Xe: cloud-init does not run before local-fs is mounted | 22:29 |
| rharper | bootcmd is the earliest path, but rootfs and /var are required. | 22:30 |
| blackboxsw | rharper: will double check that bug expansion bot ubot5 config w/ paride | 22:30 |
| rharper | falcojr: re: v2 to other formats we're lacking robust "round-trip" rendering, we have a few of those in unittests, but it's not complete; there's also some subtle issues with v2 dhcp *and* nameservers; that is, the expectation is that if you've enabled dhcp on your interface, you are getting DNS from your dhcp response ... netplan does have dhcp-overrides which allow users to ignore the DNS or Route reponse from the dhcp server | 22:35 |
| rharper | ... for sure, cloud-init internal network state is not checking if that's set and adjusting whether we keep dns information around to be rendered to something else. | 22:35 |
| rharper | falcojr: that said, in the orignal config, the overrides are not in place, so even if the nameserver is set , it's not going to get used as the dhcp client DNS will be used instead (without override). | 22:36 |
| rharper | the internal state will also need to account for per-interface dns settings which can be configured in netplan/systemd ; I believe they can be set in sysconfig (per ifcfg-$IFACE file) but I'm not sure what exactly happens when you have DHCP=yes and NAMESERVERS=XXXX in sysconfig (and I'm sure it's per-distro specific, ie, rhel vs suse likely differ in whether DHCP DNS settings override or are ignored) | 22:37 |
| blackboxsw | rharper: thx for context. falcojr too, here's a patch (I avoided extra indenting of unchanged lines for clarity of functional changeset) https://paste.ubuntu.com/p/y5dQQn3FJF/ | 22:40 |
| blackboxsw | but basically v2 we need to actually look into each specific device "nameservers" settings and look for "addresses" . We also need to set "address" as the command key we pass into handle_nameserver() as that's the "v1" command the internal state parses | 22:41 |
| rharper | addresses and search | 22:42 |
| blackboxsw | that'll kindof help the photonos folks | 22:42 |
| falcojr | cool, thanks for all the help and info | 22:43 |
| blackboxsw | when I apply that patch I see the following internal state: line 41-49 https://pastebin.ubuntu.com/p/gMz4Xrr287/ | 22:43 |
| blackboxsw | using the same "source" v2 | 22:43 |
| falcojr | gotcha, that makes sense | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!