=== ijohnson|lunch is now known as ijohnson
=== apollo13_ is now known as apollo13
[16:57] <slingamn> i'm thinking about trying to remove python3-requests as a dependency of cloud-init
[16:58] <slingamn> what's the oldest python supported by cloud-init?
[17:00] <powersj> slingamn, saw your conversation in #ubuntu-devel, what is driving the desire to remove it?
[17:00] <powersj> ftr, python 3.4 per https://lists.launchpad.net/cloud-init/msg00227.html
[17:00] <slingamn> i don't like that python3-requests has become necessary core infrastructure for linux
[17:01] <slingamn> it's too big and too sloppy
[17:01] <slingamn> and it's either obsolete or unnecessary for API calls
[17:02] <slingamn> short writeup in this issue comment: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1903605/comments/4
[17:02] <ubot5> Ubuntu bug 1903605 in apport (Ubuntu) "proposed patch: remove dependency on python3-requests" [Medium,Fix released]
[17:49] <Odd_Bloke> slingamn: Unless you can provide very convincing arguments, I don't see us accepting that change upstream: it would represent a major change to cloud-init with limited upside.  As an example of what could break: users can configure cloud-init to include remote configuration via HTTP, which could come from any HTTP endpoint whatsoever; your assertion that chardet is not necessary seems less likely to hold
[17:49] <Odd_Bloke> there.  Also, your reasoning in the linked comment is at least partially invalid: per the package description of python3-certifi, "The version of certifi in this Debian package is patched to return the location of Debian-provided CA certificates, instead of those packaged by upstream."
[17:49] <slingamn> remote configuration?
[17:50] <Odd_Bloke> slingamn: https://cloudinit.readthedocs.io/en/latest/topics/format.html#include-file
[17:51] <slingamn> that's a good point about certifi
[17:52] <slingamn> sorry, i don't really understand this use case with include files
[17:54] <Odd_Bloke> slingamn: So you can provide config to cloud-init via user-data in most clouds: this could be a shell script (which cloud-init will execute) or cloud-config YAML (which cloud-init will handle appropriately).  It could also be an include file, which specifies a list of URLs which cloud-init will fetch and treat as user-data.
[17:55] <Odd_Bloke> So "#include\nhttp://example.com/user-data\nhttp://myproject.example.com/some-specific-data" would fetch those two URLs.
[17:56] <slingamn> oh sorry i think i don't even understand the concept of user-data here
[17:57] <Odd_Bloke> You don't really need to: the point is that we need to be able to fetch arbitrary URLs (which therefore cannot be trusted to even be compliant HTTP servers) and unless the requests replacement is bug-compatible, then we may regress users.
[17:57] <slingamn> hmm, ok
[17:57] <Odd_Bloke> So we need to weigh the benefit of not using requests (which I am yet to be convinced of :) against the risk of regressing users.
[17:58] <slingamn> yeah that's probably a dealbreaker
[17:58] <Odd_Bloke> Hence the need for very convincing arguments. ;)
[17:59] <Odd_Bloke> I appreciate the line of inquiry, I'm always keen to strip out dependencies if we can. :)
[18:00] <slingamn> thanks for explaining :-)
[18:02] <Odd_Bloke> :)
=== ijohnson is now known as ijohnson|lunch
[18:34] <falcojr> Odd_Bloke and blackboxsw: here's my notes on my apply_network_config digging
[18:34] <falcojr> https://gist.github.com/TheRealFalcon/42083a9062a15ccdfdabe03ff598efa9
[18:35] <falcojr> I want to refactor it to only apply config at local stage and see if that breaks anything
[19:22] <Odd_Bloke> falcojr: Great, thanks!
[19:29] <Odd_Bloke> Integration tests are currently working if I run `pytest` (even in a fresh virtualenv with only the integration requirements installed) but failing if I run `tox -re integration-tests`. ;.;
[19:33] <falcojr> I saw a problem like that once...if I was running tox itself from within a virtualenv it did weird things
[19:33] <falcojr> didn't really investigate it though so not sure why that would be the case
[20:29] <blackboxsw> Odd_Bloke: I think I've gotten  out of the way on Azure UUID case-insensitive comparison now  https://github.com/canonical/cloud-init/pull/798
=== ijohnson|lunch is now known as ijohnson
[20:39] <Odd_Bloke> blackboxsw: You mean you've reverted to doing it the way you were doing it before I got in the way? ;)
[21:07] <blackboxsw> Odd_Bloke: yeaaaaah but we now ping the image serial :). And we now have more context about bionic vs xenial Azure fips/non-fips behavior.
=== powersj changed the topic of #cloud-init to: 20.4 (Nov 24), 21.1 (Feb 22) | file a bug: https://bugs.launchpad.net/cloud-init/+filebug | pull-requests: https://git.io/JeVed | meeting minutes: https://goo.gl/mrHdaj | next office hours: TBD
[22:13] <johnsonshi> Hey all, this PR has been approved and is ready for merging now: https://github.com/canonical/cloud-init/pull/800
[22:14] <johnsonshi> Thanks! :)