| === vrubiolo1 is now known as vrubiolo | ||
| powersj | Odd_Bloke, in this SRU we added the man pages https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725 | 15:24 |
|---|---|---|
| ubot5 | Ubuntu 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 |
| powersj | however I don't see man pages when launching instances in lxc or multipass | 15:24 |
| Odd_Bloke | powersj: I don't think we ever made the packaging branch changes to include them; 796f58081766c51cdb36e770541d32f84f595371 added them to master's packaging. | 15:29 |
| powersj | ah right, I forgot about the debian dir change | 15:53 |
| Odd_Bloke | falcojr: The minor fix I mentioned in stand-up: https://github.com/canonical/cloud-init/pull/731 | 17:11 |
| Odd_Bloke | Just 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 |
| powersj | rharper, 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 ec2 | 18:23 |
| rharper | powersj: 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 |
| rharper | ah, right, we know its *not* openstack on x86 so we don't query | 20:27 |
| rharper | powersj: so yeah, non-x86 is penalized since we *cant* know | 20:28 |
| rharper | ok, that makes sense; | 20:28 |
| powersj | rharper, and this behavior is only on xenial? | 20:28 |
| powersj | as in the release that goes end of standard support in 4 months? | 20:28 |
| rharper | powersj: 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 behavior | 20:46 |
| rharper | s/arm64/non-x86 xenial | 20:47 |
| powersj | ok then, could we merge his code and keep a packaging change to revert it on xenial? | 20:47 |
| rharper | well, 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 once | 20:57 |
| Odd_Bloke | PR to add more Python versions to CI: https://github.com/canonical/cloud-init/pull/734 | 21:23 |
| Odd_Bloke | In 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 our | 21:31 |
| Odd_Bloke | minimum supported version to 3.5? | 21:31 |
| Odd_Bloke | What 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 |
| ajmyyra | are there even any LTS-supported distros that use less than 3.5 by default anymore? | 21:33 |
| Odd_Bloke | There 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_Bloke | falcojr: Thanks for the review! | 21:35 |
| powersj | Odd_Bloke, you need to check-in with SuSE re: 3.4 | 23:03 |
| powersj | SuSE 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 forward | 23:05 |
| powersj | as you said xenial is our only 3.5 and that is ending soon as well | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!