=== vrubiolo1 is now known as vrubiolo
powersjOdd_Bloke, in this SRU we added the man pages https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/185972515:24
ubot5Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,In progress]15:24
powersjhowever I don't see man pages when launching instances in lxc or multipass15:24
Odd_Blokepowersj: I don't think we ever made the packaging branch changes to include them; 796f58081766c51cdb36e770541d32f84f595371 added them to master's packaging.15:29
powersjah right, I forgot about the debian dir change15:53
Odd_Blokefalcojr: The minor fix I mentioned in stand-up: https://github.com/canonical/cloud-init/pull/73117:11
Odd_BlokeJust to update folks: we have completed validation of the 20.4 SRU (the process by which it is released to stable Ubuntu releases), but given the proximity to the end of the year, we'll be holding off on actually releasing the update until the start of next year.17:12
powersjrharper, if you didn't see I ran those tests for the openstack timeout. On arm64 you can clearly see the timeout affect boot time on ec218:23
rharperpowersj: yeah, just saw that ... I didn;t look at the logs yet;   so you didn't see a delay on x86?  I would have expected both ...20:26
rharperah, right, we know its *not* openstack on x86 so we don't query20:27
rharperpowersj: so yeah, non-x86 is penalized since we *cant* know20:28
rharperok, that makes sense;20:28
powersjrharper, and this behavior is only on xenial?20:28
powersjas in the release that goes end of standard support in 4 months?20:28
rharperpowersj: so for arm64 on ec2; newer than xenial, ds-identify will positively identify ec2 and not put Openstack in the datasource list; so that code never will run; on Xenial, we still probe the whole list (even if ds-identify says it's just ec2) to retain existing behavior20:46
rharpers/arm64/non-x86 xenial20:47
powersjok then, could we merge his code and keep a packaging change to revert it on xenial?20:47
rharperwell, it's worth testing a focal arm64 with the change  to confirm;  I guess I'd also like to see about the retry without the extra long timeout ... it doesn't seem quite right to only try the metadata server just once20:57
Odd_BlokePR to add more Python versions to CI: https://github.com/canonical/cloud-init/pull/73421:23
Odd_BlokeIn the course of ^, I discovered that we broke 3.4 (with a SyntaxError, so on import) with a commit in May, which was released in 20.3 (in August).  As we haven't heard any complaints about that, AFAIK, it seems to me like 3.4 support is not really being used.  I'm wondering if we can declare cloud-init 20.2 to be the last cloud-init release with 3.4 support, cut a stable-20.2 branch, and raise our21:31
Odd_Blokeminimum supported version to 3.5?21:31
Odd_BlokeWhat do folks think?21:31
Odd_Bloke(We won't make a decision until the new year, as plenty of folks are already out; just taking the temperature on the proposal. :)21:32
ajmyyraare there even any LTS-supported distros that use less than 3.5 by default anymore?21:33
Odd_BlokeThere aren't Ubuntu LTS releases, no (xenial is 3.5); CentOS do still have a supported version that uses 3.4, but my understanding is that cloud-init isn't backported to that particular release.21:34
Odd_Blokefalcojr: Thanks for the review!21:35
powersjOdd_Bloke, you need to check-in with SuSE re: 3.423:03
powersjSuSE was why we kept 3.4 in for a bit longer. I was hoping this last summit we could have decided on a date for moving forward23:05
powersjas you said xenial is our only 3.5 and that is ending soon as well23:05

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!