=== cpaelzer_ is now known as cpaelzer
=== cpaelzer_ is now known as cpaelzer
=== rharper_ is now known as rharper
=== milosz_ is now known as milosz
[20:21] <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:28] <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:45] <saimsh> @falcojr this is very helpful. Thank you very much :)
[20:46] <saimsh> just to be sure the unverified
[20:47] <saimsh> oops .. hit enter
[20:48] <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:52] <falcojr> saimsh: resolv_conf (with the underscore)
[20:53] <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
=== meena6 is now known as meena
[21:40] <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:41] <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:42] <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:44] <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?
[22:05] <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:10] <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: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 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:20] <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:28] <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:29] <rharper> Xe: cloud-init does not run before local-fs is mounted
[22:30] <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:35] <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:36] <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:37] <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:40] <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:41] <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:42] <rharper> addresses and search 
[22:42] <blackboxsw> that'll kindof help the photonos folks
[22:43] <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