[13:28] <meena> I've been invited to the canonical org again!
[13:28] <Odd_Bloke> meena: powersj: Yep, it was so we could request you as a reviewer; we're adding you back ATM.
[13:29] <Odd_Bloke> (Our IS department are introducing automation to sync LDAP and GitHub to ease starter/leaver tasks; you just need adding to an allowlist. :)
[16:32] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/493 is no longer WIP, and is ready for review/landing.
[17:42] <Odd_Bloke> smoser: rharper: Given ds-identify should mean that we only use the OpenStack DS when we should expect a response, https://github.com/canonical/cloud-init/pull/501 seems like a reasonable change; any thoughts?
[18:02] <smoser> so current behavior is it will try once, with a socket timeout of 10 seconds ?
[18:02] <smoser> before ditching it?
[18:04] <smoser> non-intel is an issue
[18:24] <rharper> Odd_Bloke: I wonder if we should order the 90_dpkg.cfg datsource_list by increasing timeout?   for non-intel, they are trying all ds ; NoCloud, ConfigDrive, OpenNebula, DO, Azure, AltCld, OVF, MAAS, GCE before openstack ;   for intel they'll head right for it (and not trying anything else);
[18:34] <Odd_Bloke> Oh, because non-Intel don't (necessarily) have DMI data?
[18:37] <rharper> correct
[18:38] <rharper> so it's a maybe and you don't get the short list
[18:39] <rharper> beyond optimization; for non-ds id paths;  the change seems fine; though going from 10 to 120 is a big jump for timeouts;    but generally I don't think there's anything wrong with the change;
[20:45] <smoser> its hard... because the truth is, if your metadata service isn't there, its because you have a failed cloud.
[20:46] <smoser> in the past 10 years, i have never seen ec2 metadata service down.
[20:46] <smoser> but, imo because of bad design, every openstack has issues with terribly slow metadata service.
[20:47] <smoser> so one par tof me says "sure, change cloud-init to work better on your little toy"
[20:47] <smoser> and the other part says "fix your silly cloud."
[20:48] <smoser> but we do not want a larrge timeout on non-intel unless there is only one datasource in the list.
[21:06] <rharper> smoser: we had a similar discussion around ipv6 imds for openstack ...   without a non-networky way to know whether it's worth waiting or not; you just end up waiting;