/srv/irclogs.ubuntu.com/2022/02/14/#cloud-init.txt

=== Guest783 is now known as Daniel
max2Hello, is it possible to disable renaming of network interfaces without touching user-data in the cloud-init drive?11:46
max2i3l11:48
jellyfrogIs 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 example15:03
minimaljellyfrog: for NoCloud-Net you can load meta-data and user-data via http/https15:07
minimalwhether you provide the URL as you indicated or you "hard-code" the url in /etc/cloud/cloud.cfg15:07
jellyfrogminimal: yes, but im asking if i can provide the url via dhcp15:09
minimaljellyfrog: don't believe so, what DHCP option would/could provide that? the bootfile-name one?15:12
jellyfrogcustom I suppose. I'm coming more from the "pxe-world", I could ofc pxe boot a machine, and modifify the kernel arguments15:13
minimaljellyfrog: with NoCloud and "seed" urls I found the network side is not actually provided by NoCloud, rather the DHCP happens via the "fallback" DS/mode15:15
minimalAFAIK 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 option15:16
jellyfrogminimal: well it could be a "standard" from cloud-init side :) 15:19
minimaljellyfrog: 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:21
jellyfrogminimal: hmm, ok doesnt sound too good, but I suppose the name of the project says what its focused on :)15:27
minimaljellyfrog: I use cloud-init for configuring physical/VM/Cloud machines :-)15:30
jellyfrogminimal: thanks, seems some testing is in order.15:45
minimaljellyfrog: 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)15:47
holmanbjellyfrog: What do you think would be the benefit of setting config via dhcp over config via kernel args via pxe?16:09
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:12
blackboxswholmanb: oops. I'll pul a followup PR for that. I saw your first comment and missed the 2nd cone16:14
blackboxsw2nd one16:14
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
blackboxswholmanb: 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:17
blackboxswahh because you are thinking we can do this in jsonschema potentially16:18
holmanb@blackboxsw: Yes16:18
holmanbSupporting 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 schema16:19
blackboxswthe other thing I was wondering is this support would also potentially be distro release specific too right16:19
blackboxswso we might want to disallow certain hash formats on Bionic that are understood on Jammy16:19
holmanbblackboxsw: yes, if we add support for parsing $y, that will be recognized as a hash on bionic even though it isn't supported by crypt16:19
blackboxswholmanb: 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:21
holmanb@blackboxsw - correct, however our docs don't specify supporting $y, so that would be user err16:22
blackboxswyes, but also a reasonable feature for cloud-init too. :)16:23
holmanbyep16:23
holmanbcrypt.methods has the information we would need for "whether this distro supports $X hash method"16:24
holmanberr, maybe not16:25
blackboxswI'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 definition16:25
holmanbseems the docs in 3.10 don't reflect latest hashes that crypt support16:26
blackboxswyeah 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 needed16:26
holmanbblackboxsw: ack, sounds good to me16:26
blackboxswholmanb: 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 shape16:30
blackboxswintegration 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_cloud16:32
max2Can someone tell me, if it's possible to disable the change of NIC names within `/etc/cloud/` - without touching user-data?16:46
max2I'd like to use the provided configuration just without the name16:47
minimalmax2: NIC's are not referenced in user-data AFAIK, rather in network-config16:50
blackboxswmax2: 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
max2Sure, minimal, I know. But it's also possible to not use network-config but user-data.16:51
max2For that matter, in my case it's contained in network-config16:51
max2blackboxsw: I actually want the rest of the configuration, just not the configured names. Disabling the whole network configuration won't do the trick for me16:52
max2So this is yet another use case, it's not designed for?16:57
blackboxswmax2: 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:58
blackboxswthe reason being that user-data might be pulled down from a network source, so network needs to be up before processing user-data.16:59
max2I'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:01
blackboxswmax2: 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-hotplug17:14
blackboxswoops think we lost max217:14
blackboxswhrm 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:46
blackboxswahh nevermind, not a cloud-init config service.18:48
blackboxswalso, 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:06
blackboxswit may just be the instance size we are execing tests on not getting CPU time on hosts, but I'm not sure19:09
blackboxswI 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 boots19:10
blackboxswand 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 believe19:17
holmanbblackboxsw: yikes, agreed that should be investigated19:18
holmanbblackboxsw: 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/issue4430919:18
blackboxswyeah the main prob is our jenkins jobs also timeout at 3 hours. So we get false failures once we cross that threshold too.19:18
holmanbwe 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:20
blackboxswholmanb: 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
ubottuPull 26527 in python/cpython "[3.10] bpo-44309: Add support for yescrypt in crypt. (GH-26526)" [Closed]19:23
blackboxswso 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 there19:24
blackboxswazures 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#L206319:28
blackboxswahh and reading comprehension for the win: "- We still plan to deprecate and remove the crypt module because it's not reliable." 19:30
holmanbyeah the deprecation was the primary concern there19:36
blackboxswinteresting. 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 moment19:36
holmanbblackboxsw: 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 with19:42
holmanbs/container/contain/19:42
blackboxswand 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."19:56
cjp256blackboxsw: did you by chance sort that out?22:03

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