=== Guest783 is now known as Daniel
[11:46] <max2> Hello, is it possible to disable renaming of network interfaces without touching user-data in the cloud-init drive?
[11:48] <max2> i3l
[15:03] <jellyfrog> Is it possible to load cloudinit config via DHCP? ie to dynamically provide the values "ds=nocloud-net;s=http://10.10.0.1:8000/" for example
[15:07] <minimal> jellyfrog: for NoCloud-Net you can load meta-data and user-data via http/https
[15:07] <minimal> whether you provide the URL as you indicated or you "hard-code" the url in /etc/cloud/cloud.cfg
[15:09] <jellyfrog> minimal: yes, but im asking if i can provide the url via dhcp
[15:12] <minimal> jellyfrog: don't believe so, what DHCP option would/could provide that? the bootfile-name one?
[15:13] <jellyfrog> custom I suppose. I'm coming more from the "pxe-world", I could ofc pxe boot a machine, and modifify the kernel arguments
[15:15] <minimal> jellyfrog: with NoCloud and "seed" urls I found the network side is not actually provided by NoCloud, rather the DHCP happens via the "fallback" DS/mode
[15:16] <minimal> AFAIK there's no support for what you're wanting to do. Even if there was, if you want to use a custom DHCP option there's no way to specify which option
[15:19] <jellyfrog> minimal: well it could be a "standard" from cloud-init side :) 
[15:21] <minimal> jellyfrog: I played with NoCloud seedfrom recently and for example found it currently ignored a network-config file placed in the seed directory and only uses the DHCPv4 fallback (I was interested in using DHCPv6 and some other settings)
[15:27] <jellyfrog> minimal: hmm, ok doesnt sound too good, but I suppose the name of the project says what its focused on :)
[15:30] <minimal> jellyfrog: I use cloud-init for configuring physical/VM/Cloud machines :-)
[15:45] <jellyfrog> minimal: thanks, seems some testing is in order.
[15:47] <minimal> jellyfrog: I'm only done minimal testing of seed URLs so far (mainly due to the inability to embed network-config file in the OS image)
[16:09] <holmanb> jellyfrog: What do you think would be the benefit of setting config via dhcp over config via kernel args via pxe?
[16:12] <holmanb> @blackboxsw: I saw you merged #1252. I'm going back on my suggestion that we should update the parsing code to add support for hashes of the format $y/etc. 
[16:14] <blackboxsw> holmanb: oops. I'll pul a followup PR for that. I saw your first comment and missed the 2nd cone
[16:14] <blackboxsw> 2nd one
[16:17] <holmanb> @blackboxsw: Sounds good. Related: I'm not sure we should continue maintaining the magic string parsing long term, which was discussed on IRC a month or so back. I'm hoping to maybe add a better structured schema to that module in 22.2, time willing. 
[16:17] <blackboxsw> holmanb: so that I understand you last comment here. Why do you not think we should update the documented format or handling in our cc_set_passwords?
[16:18] <blackboxsw> ahh because you are thinking we can do this in jsonschema potentially
[16:18] <holmanb> @blackboxsw: Yes
[16:19] <holmanb> Supporting the new format needs to happen, but since we don't have anyone chomping at the bit for newer formats, we could introduce support when refactoring the new schema
[16:19] <blackboxsw> the other thing I was wondering is this support would also potentially be distro release specific too right
[16:19] <blackboxsw> so we might want to disallow certain hash formats on Bionic that are understood on Jammy
[16:19] <holmanb> blackboxsw: yes, if we add support for parsing $y, that will be recognized as a hash on bionic even though it isn't supported by crypt
[16:21] <blackboxsw> holmanb: if we don't add $y support to our hashed pw checks you linked to in https://github.com/canonical/cloud-init/blob/bae9b11da9ed7dd0b16fe5adeaf4774b7cc628cf/cloudinit/config/cc_set_passwords.py#L168 then we risk ignoring those hash types in #cloud-config right?
[16:22] <holmanb> @blackboxsw - correct, however our docs don't specify supporting $y, so that would be user err
[16:23] <blackboxsw> yes, but also a reasonable feature for cloud-init too. :)
[16:23] <holmanb> yep
[16:24] <holmanb> crypt.methods has the information we would need for "whether this distro supports $X hash method"
[16:25] <holmanb> err, maybe not
[16:25] <blackboxsw> I'm game for us having an extra PR to add that since it will inevitably be asked for at some point. But yes we can probably add that once we are done w/ JSON schema effort as we'll have a better understanding of our #cloud-config validation and error messages for  cc_set_passwords modules once we carve up that schema definition
[16:26] <holmanb> seems the docs in 3.10 don't reflect latest hashes that crypt support
[16:26] <blackboxsw> yeah I had poked at crypt.methods which only had a delta of BLOWFISH on Jammy vs bionic. but I didn't think that gave us what we needed
[16:26] <holmanb> blackboxsw: ack, sounds good to me
[16:30] <blackboxsw> holmanb: falcojr: paride I'm going to sync tip of cloud-init github -> Launchpad and kickoff a daily recipe build and integration tests. I want to see what integration test failures (flaky tests) we still have on Azure per our JIRA card SC-794. I think between the incorrect integration test fixes for apt and the crypt password hash testing and cjp256's mount options changes we should be in pretty good shape
[16:32] <blackboxsw> integration test failures I haven't tried validating yet on azure: tests/integration_tests/modules/test_jinja_templating.py::test_runcmd_with_variable_substitution and  tests/integration_tests/network/test_net_config_load.py::test_network_disabled_via_etc_cloud
[16:46] <max2> Can someone tell me, if it's possible to disable the change of NIC names within `/etc/cloud/` - without touching user-data?
[16:47] <max2> I'd like to use the provided configuration just without the name
[16:50] <minimal> max2: NIC's are not referenced in user-data AFAIK, rather in network-config
[16:51] <blackboxsw> max2: I don't think we support that granularity currently. You either have all of cloud-init's network rendering features, or none via adding /etc/cloud/cloud.cfg.d/my.cfg with "network: {config: disabled}"
[16:51] <max2> Sure, minimal, I know. But it's also possible to not use network-config but user-data.
[16:51] <max2> For that matter, in my case it's contained in network-config
[16:52] <max2> blackboxsw: I actually want the rest of the configuration, just not the configured names. Disabling the whole network configuration won't do the trick for me
[16:57] <max2> So this is yet another use case, it's not designed for?
[16:58] <blackboxsw> max2: yeah at the moment there is not a knob you can set in cloud-init or /etc/cloud/cloud.cfg.d to disable nic rename from what I can tell. Also, as minimal stated, network-config is different from vendor-data and user-data. And network-config can't be overriden by user-data anyway because network-config is written to the system and brought up before user-data is even processed.
[16:59] <blackboxsw> the reason being that user-data might be pulled down from a network source, so network needs to be up before processing user-data.
[17:01] <max2> I've seen network-config inside user-data. Does that mean, it's designed to allow dual-stage network setups, but it's not possible to disable single features?
[17:14] <blackboxsw> max2: the only network config in user-data is potentially opting into network hotplug post boot @ https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=hot%20plug#install-hotplug
[17:14] <blackboxsw> oops think we lost max2
[18:46] <blackboxsw> hrm I really don't like that I'm seeing the new cc_keyboard module as one of the top blames in cloud-init related boot time on azure "10:15:40           2.203s keyboard-setup.service" this should be a noop unless "keyboard:" is specified.
[18:48] <blackboxsw> ahh nevermind, not a cloud-init config service.
[19:06] <blackboxsw> also, something still feels not quite right with boot times  to ssh access through pycloudlib in our integration tests. We're seeing both azure and ec2 instances in tests take 3-4 minutes to come up in testing across ubuntu series. Something is sluggish and it is really not helpful for getting through testruns in a timely manner.
[19:09] <blackboxsw> it may just be the instance size we are execing tests on not getting CPU time on hosts, but I'm not sure
[19:10] <blackboxsw> I think it may be worth our integration tests sshing into the node under test when boot times take an uncharacteristic amount of time to inspect what systemd-analyze blame thinks it has spent time on during those specific boots
[19:17] <blackboxsw> and seeing that current jenkins test runs are at 62% after 2 hr 8 mins  versus the previous timer run which hit 62% at 1hr 19 mins. Does not bode well for throughput during US working hours. 50% slower test execution I believe
[19:18] <holmanb> blackboxsw: yikes, agreed that should be investigated
[19:18] <holmanb> blackboxsw: I was wondering why python's crypt module doesn't support more recent algos and I noticed this attempt to add yescrypt support: https://bugs.python.org/issue44309
[19:18] <blackboxsw> yeah the main prob is our jenkins jobs also timeout at 3 hours. So we get false failures once we cross that threshold too.
[19:20] <holmanb> we don't make heavy use of crypt, but enough that deprecation in python would be disruptive (azure datasource, netbsd distro, and test_set_password.py are the prime users it looks like)
[19:23] <blackboxsw> holmanb: right per that attempt to add yescrypt to python 3.10, it looks rejected by https://github.com/python/cpython/pull/26527#issuecomment-855217022 so even 3.10 won't see that. and 3.10 is Ubuntu Jammy 22.04. focal 20.04 is 3.8 based and bionic 18.04 is only 3.6 based. 
[19:23] <ubottu> Pull 26527 in python/cpython "[3.10] bpo-44309: Add support for yescrypt in crypt. (GH-26526)" [Closed]
[19:24] <blackboxsw> so we can expect that older version of python on older releases of Ubuntu just won't have visibility in the python crypt module specifically to handle/understand yescrypt I believe. Pease correct me if I'm misinterpreting tea leaves there
[19:28] <blackboxsw> azures use of crypt looks to default to  $6$ or  SHA-512 so I'm not sure not-having yescrypt support affects their use case currently https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceAzure.py#L2063
[19:30] <blackboxsw> ahh and reading comprehension for the win: "- We still plan to deprecate and remove the crypt module because it's not reliable." 
[19:36] <holmanb> yeah the deprecation was the primary concern there
[19:36] <blackboxsw> interesting. ok hrm. So yeah, I'm not sure what we would do in that case. Needs a bit of investigation on how to move on as the crypt module is unmaintaned. https://www.python.org/dev/peps/pep-0594/ had a couple of suggestions, but not certain what we'd look to at the moment
[19:42] <holmanb> blackboxsw: good find, pep:594 suggests 3.12 will be the last to container crypt. At a glance, I don't recognize anything else concerning in pep 594, but there may be other things I'm not familiar with
[19:42] <holmanb> s/container/contain/
[19:56] <blackboxsw> and we might be hitting provisioning load errors on Azure. "12:49:03 E           msrestazure.azure_exceptions.CloudError: Azure Error: OSProvisioningTimedOut...  * If you are deploying more than 20 Virtual Machines concurrently, consider moving your custom image to  share image gallery."
[22:03] <cjp256> blackboxsw: did you by chance sort that out?