[15:19] <rharper> robjo: https://bugs.launchpad.net/suse/+source/cloud-init/+bug/1843502  ;   curious bug here around azure + suse image and network-config parsing
[15:19] <ubot5> Launchpad bug 1843502 in cloud-init "Network config is incorrectly parsed when nameservers are specified" [Undecided,Incomplete]
[15:26] <robjo> rharper: I worked with Moustafa a little bit on this, as in, help to find one place in the code why resolv.conf doesn't have the proper value. Looks like he made much more progress since
[15:27] <robjo> based on the description this appears to be a generic issue with the "v1" syntax and a typo, "address" vs. "addresses"
[15:28] <rharper> azure renders v2, so I mentioned the 'nameservers' bits need to be indented underneath the interface name (eth0)
[15:33] <robjo> Also added a comment
[15:34] <rharper> robjo: the other confusing  part (to me) was where the nameserver values came from;  it's been a while since I've looked at the contents of azure IMDS
[15:35] <rharper> robjo: thanks,  I suspect if there's no downstream changes, then it's got to be local image modifications
[15:36] <rharper> there are some odd debug messages in the log as well,
[15:36] <rharper> 2019-09-09 16:21:29,416 - handlers.py[DEBUG]: start: azure-ds/parse_network_config:
[15:36] <rharper> 2019-09-09 16:21:29,416 - DataSourceAzure.py[DEBUG]: Azure: generating network configuration from IMDS
[15:36] <rharper> 2019-09-09 16:21:29,416 - DataSourceAzure.py[DEBUG]: netconfig &s:
[15:36] <rharper> in which cloudinit has never emitted the string "netconfig &s"
[15:36] <rharper> so I'm thinking to close this out as invalid since someone is hacking their own changes into cloud-init
[15:36] <robjo> I just don't know where the nameserver information is supposed to be coming from
[15:37] <robjo> if Azure puts the info into the metadata then the data source should pick it up and make it availabe
[15:37] <rharper> so, Azure, AFAIK, only provides dns info via dhcp lease
[15:38] <robjo> if that is the case then how could network configuration via cloud-init ever work?
[15:38] <rharper> so we never explicitly generate network config with 'nameservers' values; azure is a dhcp on eth0 shop, you can dhcp on additional interfaces, and add static ips; but beyond that, I've never seen any dns info in IMDS data
[15:38] <rharper> we generate dhcp on eth0
[15:38] <rharper> and the OS's dhcp client does the rest
[15:39] <robjo> Well something triggers that resolv.conf gets written by cloud-init which prevents netconfig from writing the dns info from the dhcp server
[15:40] <robjo> There was a bug where an empty resolv.conf was written tha triggered that condition but that has since been fixed
[15:40] <robjo> OK, so now I am even more confused
[15:40] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/372622
[15:40] <smoser> if anyone intereseted
[15:41] <robjo> I guess I have to fiddle with this on my own and see what happens
[15:42] <rharper> robjo: do you have a recent boot of an unmodified sles image on azure that we can compare cloud-init.logs ?  I really suspect there's some local modifications due to that strange log output
[15:43] <robjo> Currently I am not building images with cloud-init, it would be a matter of staring a SLES instance in Azure, then adding cloud init and running cloud-init local to see what happens with network configuration
[15:44] <rharper> oh interesting, so it's almost certainly a  custom image then
[15:44] <robjo> Given the state a reboot to get a full log may not be advisable as one may not get back into the system
[15:46] <robjo> It's certainly customized w.r.t. the initialization code, I am not certain Moustafa made any changes to the cloud-init package delivered in the SUSE repos
[15:47] <rharper> I'll ask explicitly,  would rpm -verify cloud-init tell us if anything has changed?
[15:54] <robjo> yes that would be expected
[16:20] <rharper> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/372624
[16:56] <smoser> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/372624
[16:56] <smoser> rharper: ^
[17:26] <rharper> smoser: replied
[17:30] <smoser> thanks
[20:08] <smoser> rharper: you can approve https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/372622 if you approve my dropping of the bug url
[20:08] <smoser> that was your only question) and Odd_Bloke already approved.
[20:27] <rharper> smoser: sure;
[20:29] <rharper> smoser: hrm, I was hoping for a new url to a bug indicating that we needed to narrow the definition , ie, the reason for the bug ;  was that unclear ? or do you feel it's unnecessary ?
[20:30] <rharper> that is, if someone else were to add another look-a-like like zstack and brightbox, the comment could indicate that we want to make sure it doesn't widely match other domain names
[20:33] <smoser> i think its unnecessary.
[20:33] <smoser> git log / blame will indicate the bug
[20:33] <smoser> and (for zstack) there will be a doc/datasources/zstack
[20:34] <smoser> code does not need references like that.
[20:34] <smoser> when i went looking, i did a git log, didn't even see the in-file comment.
[20:38] <rharper> ok
[21:26] <blackboxsw> rharper: Goneri I've updated my review comments on https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507
[21:26] <blackboxsw> one minor behavioral thing I'd like to have fixed. but otherwise looks good to me
[21:32] <blackboxsw> btw I'm also going to add Goneri to our CI group given the number of branches proposed (it'll automate CI runs on any new branch pushes)
[21:32] <blackboxsw> welcome to the CI team Goneri :)
[21:33] <blackboxsw> you'll get CI votes on your branches from here on out
[21:37] <rharper> blackboxsw: +1
[22:00] <Goneri> blackboxsw, thanks for the review and the group inclusion :-)