[10:38] <otubo> vijayendra: doesn't openstack have a dhcp service? IIRC, when an instance deployed with cloud-inti is on a ipv4 network, the link local interface comes up with its addr 169.254.0.0/16 to get metadata from OpenStack.
[10:39] <otubo> vijayendra: perhaps I don't know exactly how PowerVS works here, does it uses the full implementation of OpenStack?
[11:08] <vijayendra> otubo, PowerVC/VS doesn't use complete openstack services, It doesn't use DHCP service provided by openstack. VM's are statically configured using ConfigDrive
[11:09] <otubo> vijayendra: would you have your network yaml configuration to share? I'm implementing the support for cloud-init set some more network options on sysconfig.
[11:10] <vijayendra> otubo, here is sample network_data.json looks like https://paste.ubuntu.com/p/Tb5vk6SgT4
[11:13] <otubo> ok
[11:13] <vijayendra> otubo, cloud.cfg:  https://paste.ubuntu.com/p/KbNGjqHYYq/
[11:14] <otubo> vijayendra: I might need the network_data.json as well
[11:15] <otubo> vijayendra: I need a yaml configuration like this https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#examples
[11:16] <vijayendra> otubo, this is network_data.json only https://paste.ubuntu.com/p/Tb5vk6SgT4
[11:17] <vijayendra> you can see step  cat 1.json
[11:21] <vijayendra> otubo, we don't have this network yaml config in our setup. I believe cloudinit just uses this network_data.json
[11:24] <vijayendra> otubo, cloudinit is not using any other config here https://paste.ubuntu.com/p/8q84fGC74s/
[11:32] <vijayendra> otubo, let me check configDrive once again, if it has any network yaml
[11:40] <vijayendra> otubo, I don't find any network yaml inside config drive too https://paste.ubuntu.com/p/WbmsnyJDG4/
=== cpaelzer__ is now known as cpaelzer
[14:48] <Odd_Bloke> rharper: smoser: Do either of you know of a reason why we shouldn't fix https://bugs.launchpad.net/cloud-init/+bug/1900837?  It seems clear-cut to me, IDK if I'm missing some historical context though, as this behaviour has been in place since at least 2012.
[14:48] <ubot5> Ubuntu bug 1900837 in cloud-init "cloud-init resets permissions on log file after reboot" [High,Triaged]
[14:51] <smoser> i think there is a permissions setting on it.
[14:51] <smoser> log_file_persm
[14:52] <Odd_Bloke> I think that's owner/group.
[14:52] <smoser> yeah, and its also syslog_fix_perms
[14:52] <smoser> which may not be the cloud-init log.
[14:53] <smoser> so i agree that if it is present, we should not change perms.
[16:24] <Odd_Bloke> rharper: I'm looking at the Azure testing you asked me to do on https://github.com/canonical/cloud-init/pull/608 (apologies for missing the request the first time!); how would you anticipate failure presenting?  (My underlying question: would running the SRU script for Azure, which includes advanced networking, be sufficient to confirm that all is good?)
[16:25] <Odd_Bloke> (From reading through, it looks to me like that is likely sufficient, but some confirmation would be appreciated. :)
[16:41] <blackboxsw> :q
[16:42] <blackboxsw> oops
[17:15] <rharper> Odd_Bloke: on the azure instance, it would make the same duplicate mac complaint
[17:16] <rharper> Odd_Bloke: so a successful boot up of an instance with cloud-init and that PR is sufficient;  the ovs side and verifying normal maas bond/bridge is verified; so just checking that we don't regress azure + advanced networking;
[17:49] <Odd_Bloke> rharper: Ack, thanks!
[17:57] <meena> i'm online at a "reasonable" time, and i'm not brain-dead, and i have hardly any real work, so who's up for holding my hand, and spoon feeding me python tests?
[18:00] <meena> smoser: thanks for the start on the kenv patch
[18:05] <smoser> you're  welcome.
[18:06] <smoser> the unit tests for ds-identify are ... interesting
[18:06] <meena> if by interesting you mean gross, then, i agree.
[18:12] <meena> do i have to recompile my quemu / libvirt / kvm to temporarily fake a different vendor?
[18:15] <meena> smoser: anyway, i;d also have to refactor util.py / read_dmi_data()
[18:17] <smoser> meena: yeah, you wil have to do that too.
[18:18] <meena> anyway, i'd like to get this into the next release, cuz… well, i fucked that up last year, would be good to fix it, too…
[18:18] <smoser> and by gross... if you can find a better way to get reasonable coverage on a shell script, then go for it.
[18:19] <meena> smoser: 🙈️🙉️🙊️
[21:13] <meena> anyone else really surprised by emails from launchpad bugs, and then really disappointed that it's from you yourself