[00:12] <kbZ> powersj you around?
[00:15] <rharper> kbZ: he's out already, but should be back tomorrow morning Pacific times,
[03:52] <blackboxsw> rharper: for tomorrow https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/370970/comments/970219 my azure validation on v2 metrics branch for secondary nic. Why isn't route-metric 200  showing?
[03:52]  * blackboxsw skips out
[11:43] <otubo> Hi guys, I still can't seem to find out the reason why this thing happens, does anyone have a little bit of time to help me debug this issue? https://bugzilla.redhat.com/show_bug.cgi?id=1593010
[11:43] <ubot5> bugzilla.redhat.com bug 1593010 in cloud-init "cloud-init network configuration does not persist reboot [RHEL 7.8]" [High,Assigned]
[11:43] <otubo> (oh, cool bot!)
[11:48] <otubo> Right now I'm using 18.5 to work on, but it's no big deal to have anything newer to have backported
[11:49] <otubo> The only environment I have right now is ESXi, and I can reproduce it.
[14:25] <rharper> blackboxsw: that sure looks like a bug to me w.r.t the metric on eth1
[14:27] <rharper> I suspect that the ESXi bug is related to the OVF datasource resetting instance-id =(
[14:35] <Odd_Bloke> rharper: blackboxsw: We discussed yesterday having the new Oracle network code off-by-default for now; I'm thinking I'll name the config option "apply_network_config", following the naming in the Azure DS.  Does that sound reasonable?
[14:57] <rharper> Odd_Bloke: that sounds reasonable, yes
[15:43] <kbZ> ᕕ( ⁰ ▽ ⁰ )ᕗ
[16:28] <blackboxsw> +1 Odd_Bloke.
[17:15] <blackboxsw> rharper: ok Azure 2 nics Eoan plus route-metric.... again I am not getting any route represented with a route-metric cost of 200. Will probably need to screen share and discuss with your sometime today
[17:15] <blackboxsw> and maybe it's just that nic 2 is also on the same subnet, so the route is omitted as it's a dup
[17:16]  * blackboxsw tries switching the vnet to 10.1.0.0/16 instead of 10.0.0.0/16 (which eth0 is also on)
[17:26] <blackboxsw> hrm, looks like I am just not certain how to setup multiple nics with different routes in azure vms. two nics on separate subnets result in only one interface with routes defined from the dhcp server.
[17:37] <rharper> blackboxsw: hrm
[17:37] <rharper> lemme verify on my openstack instances
[17:40] <rharper> blackboxsw: is that with or without the systemd with classless static route fix ?
[17:41] <blackboxsw> rharper: right, eoan is without the classless route fix. lemme bump it to -proposed
[17:41] <blackboxsw> and grab the queued fix for that too
[17:41] <rharper> no I was hoping without
[17:41] <blackboxsw> ok
[17:41] <rharper> I've a bionic instance that's doing it right
[17:41] <rharper> so I need to see what's different
[17:41] <rharper> can you import my ssh keys? lp:raharper  ?
[17:41] <rharper> and let me know where the instance is at ?
[17:43] <rharper> http://paste.ubuntu.com/p/gkhGkYqQfG/
[18:16] <Odd_Bloke> rharper: blackboxsw: On reflection, I don't think apply_network_config is the right name; in other places that disables DS-provided network config entirely which wouldn't be the meaning here.  I'm leaning towards apply_imds_network_config.  What do you think?
[18:17] <rharper> would you update the Azure one as well ? I agree we had some confusion over what it meant
[18:18] <rharper> Azure would accept both
[18:18] <rharper> or check both ?
[18:19] <blackboxsw> rharper: Odd_Bloke +1 on Azure ds_cfg needed to accept both, as apply_network_config on Azure currently means read IMDS and use it.
[18:21] <blackboxsw> hrm Odd_Bloke which datasource has apply_network_config disabling network config completely? OpenStack? I'd suggest that it is the same meaning in OpenStack as Azure. OpenStack's network_data.json is complex network config for the instance from OpenStack's IMDS. If we ignore it, w/ apply_network_config false, we aren't disabling network completely, just relying on fallback dhcp on primary nic (like azure does)
[18:23] <Odd_Bloke> I didn't say we disabled network completely, I said we disable _DS-provided_ network.  But, yeah, I see that that's not quite what it's doing on Azure.
[18:23] <blackboxsw> ... I'm probably misreading sorry.
[18:23] <Odd_Bloke> (On OpenStack it does just return None from .network_config, which is a full disable.)
[18:23] <Odd_Bloke> (On Azure it generates its own fallback config with slight modifications to the call.)
[18:24] <blackboxsw> ahh right, shoot. I thought cloudinit/stages.py did a fallback config if ds.network_config == None. I see now the LOG.info("network config is disabled by %s", src)
[18:25] <Odd_Bloke> I'm pretty sure stages _does_ do a fallback config.
[18:26] <Odd_Bloke> Yeah, a DS has to return {'config': False} to disable _all_ networking.
[18:27] <blackboxsw> looks like true: Init._find_networking_config walks through each potential network source, if ds.network_config == None, it still walks to self.distro.generate_fallback_config()
[18:27] <Odd_Bloke> Returning None from ds.network_config is just indicating that the DS doesn't have any network configuration to apply.
[18:27] <blackboxsw> right +1
[18:28] <blackboxsw> cloudinit/stages.py:line 644 is the catchall if no applicable network config from ds initramfs kernel_cmdline etc
[18:28] <blackboxsw> ok
[18:28] <Odd_Bloke> So I think the Azure behaviour and the OpenStack behaviour are quite similar, in that they both result in fallback configuration being emitted.
[18:28] <blackboxsw> in either case, I'm not opposed to a more specific config option name apply_imds_network_config
[18:29] <blackboxsw> better to avoid vague interpretations as to the config option meaning
[18:29] <Odd_Bloke> The Oracle behaviour of this flag is different; we will always generate the initramfs configuration (i.e. _not_ fallback), the flag only affects whether you get configuration for your _secondary_ NICs.
[18:30] <Odd_Bloke> I think this being interaction with an IMDS is a red herring naming-wise, actually.
[18:30] <Odd_Bloke> Perhaps `configure_secondary_nics`?
[18:30] <blackboxsw> AHH
[18:31] <blackboxsw> sure, though in Azure's case apply_network_config == True has the side-effect of being the only option that'll get you secondary_nic config too, because otherwise it's just fallback :)
[18:31] <blackboxsw> same with OpenStack as it were
[18:32] <Odd_Bloke> Sure, apply_network_config is a stronger statement than configure_secondary_nics.
[18:32] <blackboxsw> but it is the most appropriate config option for Oracle... and I suppose we could add that alias in Azure && OpenStack to mean apply_network_config= True  if we wanted to grow similary config options for each DS
[18:32] <Odd_Bloke> I'm not sure that disabling secondary NICs is something we want to enable generically.
[18:32] <Odd_Bloke> At least, not without some intentional discussion about it.
[18:33] <blackboxsw> ahh, flipping that on it's head right, the converse would not be true in Azure/OpenStack. configure_secondary_nics == False. I get you. agreed
[18:35] <blackboxsw> rharper: ssh ubuntu@20.186.46.127
[18:35] <blackboxsw> id imported
[18:35] <rharper> y
[18:36] <blackboxsw> I'd like to have you walk me through triage if you would
[18:36] <blackboxsw> hangout?
[18:36] <rharper> yes
[19:19] <Odd_Bloke> rharper: blackboxsw: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371053 <-- Oracle secondary VNICs (WIP because I need to document the new behaviour, but otherwise ready for review)
[21:08] <chillysurfer> unfortunately i can't seem to get the emailing to the mailing list working. i've pinged the launchpad channel to see if they have any ideas. but in the meantime, the message i've been trying to send is a question about vendordata getting overwritten by userdata: https://gist.github.com/trstringer/be871f87efca0cd41e7017db0fd31798
[21:08] <chillysurfer> i dumped a gist there which was the content of the email
[21:08] <chillysurfer> let me know if you have any thoughts!
[21:12] <rharper> chillysurfer: sorry about the email trouble
[21:15] <chillysurfer> rharper: not a problem at all :)
[21:18] <rharper> https://git.launchpad.net/cloud-init/tree/tests/unittests/test_data.py
[21:18] <rharper> chillysurfer: I think looking there, that might help get the formatting right
[21:19] <rharper> I think it covers several of the jsonp merging between user/vendor data
[21:19] <chillysurfer> rharper: so my jsonp formatting is off?
[21:19] <rharper> it _looks_ like (and I need to read closer) that user-data might need to include vendor_data: {enabled: True}
[21:19] <rharper> to merge with vendor data
[21:19] <chillysurfer> oh wow
[21:19] <rharper> but I need to look at those examples too
[21:20] <rharper> because user_data can also disable vendor_data completely
[21:20] <chillysurfer> yep i see that with the /vendor_data path
[21:21] <chillysurfer> rharper: and merge_how doesn't apply to vendor data, is that correct? so even if user data and/or vendor data specify merge_how then it still won't be "included"
[21:21] <chillysurfer> is that a fair statement?
[21:21] <rharper> it can
[21:22] <rharper> but the user-data needs to include it as well
[21:22] <rharper> this is awkward
[21:22] <chillysurfer> "this is awkward" -> you mean that user-data includes merge_how to take vendor data into account?
[21:22] <rharper> requiring user-data to specify merge-how in each section
[21:22] <rharper> that is if you pass in 3 user-data mime parts
[21:22] <rharper> each one has to say the merge-how
[21:22] <chillysurfer> ah i see
[21:23] <rharper> you cant, set a _default_ merge-how
[21:23] <rharper> via cloud-config
[21:23] <chillysurfer> so for instance if user data specifies runcmd then that section needs to specify a merge_how?
[21:23] <rharper> I'd like to say, list: append : dict: recusrive: append et c
[21:23] <rharper> yes, in vendor-data and in each user-data
[21:23] <rharper> which is a real PITA
[21:23] <chillysurfer> yeah that sounds pretty rough
[21:24] <rharper> the lxd folks had a more common append and recursive update for dicts; and users could *clear* previously merged data by inserting empty list or things like that
[21:24] <chillysurfer> but how else could a vendor communicate to a user "hey we want to do this thing, but you need to specify a merge_how in runcmd, bootcmd, etc"
[21:24] <rharper> I need to read up on their implementation but was thinking that might be nicer for cloud-init
[21:24] <rharper> documentation
[21:24] <rharper> which is why it's not great
[21:25] <chillysurfer> rharper: right i see what you mean. so for lxd the user would have to deliberately clear sections, but for cloud-init it's the opposite... no action is clearing vendor data, and requires action to retain vendor data
[21:26] <rharper> well, at least I;d like some cloud-config to set the default merge mode
[21:54] <metsuke> I'm attempting to use cloud images on ESXi.  Am I able to provide a "Url to seed instance data from" on ESXi and then it will use the host's network to grab the config, or do I need to configure the VM's network first?
[22:14] <Odd_Bloke> metsuke: o/ I believe cloud-init will attempt to DHCP on the first interface in order to fetch that data, but let me double check.
[22:17] <Odd_Bloke> metsuke: OK, no, it doesn't do an ephemeral DHCP (which is what I was thinking of), but I _believe_ that it will only attempt to fetch metadata after networking is up in the host.
[22:18] <Odd_Bloke> metsuke: I'm not very familiar with ESXi or the OVF data source though, so your best bet is probably to try it and see what happens. :)
[22:20] <metsuke> That makes sense, thank you. I'm trying to make these images as barebones as possible without having to set up things like network configs manually
[22:24] <Odd_Bloke> cloud-init will configure the first interface to DHCP by default.
[22:24] <Odd_Bloke> So if you have DHCP set up, then you shouldn't need to touch network config to get the instances up, at least.
[22:25] <metsuke> Odd_Bloke: indeed, though in my particular case, a specific static IP is required for connectivity