| rharper | <akutz> Does cloud-init support https://netplan.io/reference/#dhcp-overrides? | 14:14 |
|---|---|---|
| rharper | partially, if you supply netplan to cloud-init and rendering to a distro with netplan support, then cloud-init passes the config through. cloud-init does not translate dhcp-override in v2 to eni or sysconfig to targets that don't have netplan; | 14:16 |
| rharper | <akutz> Is there a standard way to submit RFEs to cloud-init and its datasource? | 14:16 |
| rharper | we generally accept RFEs as bugs on launchpad (importance marked as wishlist) other methods are to push a PR to github with proposed changes and that'll get reviewed as well. | 14:17 |
| minimal | Hi folks. What's "TheRealFalcon"'s handle here on IRC? | 14:32 |
| paride | minimal, he's falcojr | 14:32 |
| minimal | thanks | 14:34 |
| falcojr | hey minimal: sorry, didn't see your question yet. It's not a yaml setting, it's part of the sshd_config | 14:35 |
| minimal | falcojr: a couple of quick things about 2 of your merged PRs, in #948 you introduced the "strictmodes" ssh config setting but there's no docs for it | 14:35 |
| minimal | oops, IMs in crossing :-) Ah, ok, not familiar with it, will go look at sshd_config docs | 14:35 |
| falcojr | https://man.openbsd.org/sshd_config#StrictModes | 14:36 |
| minimal | falcojr: 2nd one, in merged PR #936 the hook-hotplug script is written in bash rather than sh. I thought cloud-init had a policy of "sh" only. Locally I've modified it for "sh" as I maintain the cloud-init package for Alpine which uses "ash" (a "dash" derivative) by default so no Bash installed on my Alpine boxes | 14:37 |
| ubottu | Bug 936 in Launchpad itself "Bug listing fails to use full screen width" [Low, Fix Released] https://launchpad.net/bugs/936 | 14:37 |
| minimal | I realise the net hotplug stuff is WIP | 14:37 |
| falcojr | minimal: yeah, that's honestly just an oversight on my part. "sh" would be more universal | 14:42 |
| minimal | falcojr: like I said I've patched it locally but not yet tested it. I've also written a init.d script for cloud-init-hotplugd as you only provided systemd files. I now need to use something like QEMU Monitor to test whether these hotplug changes actually work for me :-) | 14:43 |
| falcojr | minimal: yeah, hotplug still has some iterating to do. It's going to take some time before it works everywhere | 14:47 |
| smoser | you all should delete the 'master' branch. since it is dead, and completely incorporated in the 'main' | 15:52 |
| smoser | just confusing. | 15:52 |
| falcojr | smoser: it's gone, are you looking at a local copy? | 16:08 |
| smoser | yeah, i was.. thats odd. it feels like a git oddity, i was looking at a repo that had it previously and it will still let me log/checkout upstream/master. | 16:15 |
| minimal | I'm looking at adding "doas" support to cloud-init. It's an alternative to "sudo". As it originally came from OpenBSD wondering if any of the BSD cloud-init devs are interested... | 16:15 |
| akutz | I apologize if my question was answered above, but IRC disconnected me, and I did not notice. Is there a standard way to submit RFEs for cloud-init and its datasources? | 16:31 |
| falcojr | akutz: yeah, it was answered above. "we generally accept RFEs as bugs on launchpad (importance marked as wishlist) other methods are to push a PR to github with proposed changes and that'll get reviewed as well. " | 17:27 |
| akutz | Ack, thank you. As I said, I disconnected and apparently IRC doesn't show you what you missed :( | 17:31 |
| falcojr | yeah, my power went out yesterday so I missed most of yesterday too | 17:32 |
| akutz | Y'all may have answered this as well and I missed it due to the same reason, but does cloud-init support https://netplan.io/reference/#dhcp-overrides? I see some of it in the code, but there's no mention of it in the docs. | 17:36 |
| blackboxsw | "I'm looking at adding "doas" support to cloud-init. It's an alternative to "sudo". As it originally came from OpenBSD " minimal: nice, meena or do3meli I think might be able to weigh in on that | 18:01 |
| blackboxsw | akutz: rharper answered that one.... | 18:02 |
| blackboxsw | •rharper> Ryan Harper <akutz> Does cloud-init support https://netplan.io/reference/#dhcp-overrides? | 18:02 |
| blackboxsw | 08:16 partially, if you supply netplan to cloud-init and rendering to a distro with netplan support, then cloud-init passes the config through. cloud-init does not translate dhcp-override in v2 to eni or sysconfig to targets that don't have netplan; | 18:02 |
| blackboxsw | 08:16 <akutz> Is there a standard way to submit RFEs to cloud-init and its datasource? | 18:02 |
| akutz | Ack, thanks blackboxsw! | 18:03 |
| blackboxsw | akutz: coincidentally..... top of the log for the day. | 18:03 |
| akutz | And thanks to rharper too! Is a chat log kept somewhere in the cases where I'm DCd? | 18:03 |
| akutz | ha! | 18:04 |
| blackboxsw | #community-notice: for those who missed IRC backlogs, they can always get them here https://irclogs.ubuntu.com/2021/08/13/%23cloud-init.html | 18:04 |
| akutz | What log is that blackboxsw? It doesn't show up in my buffer. | 18:04 |
| akutz | Ah, thank you. | 18:04 |
| minimal | blackboxsw: thanks, I'll ping them sometime to chat about it. I'm doing this for Alpine Linux as we're moved towards doas rather sudo in general. For now this will end up as local (i.e. not upstream cloud-init) changes as there are some differences between doas (OpenBSD) and opendoas (Linux and some other BSDs) :-( | 18:04 |
| blackboxsw | or rather here: https://irclogs.ubuntu.com/ | 18:04 |
| akutz | Good to know. Thanks again. | 18:04 |
| blackboxsw | just find the #cloud-init links per day | 18:04 |
| blackboxsw | minimal: good to know about the effort though so we have awareness for potential shared implementation approach | 18:05 |
| blackboxsw | or at least how to ping :) | 18:06 |
| blackboxsw | *who* | 18:06 |
| akutz | I filed https://github.com/canonical/cloud-init/pull/979, but given how close y'all are to 21.3, I would hold off on the PR until post release. It passes all unit tests, but on the off chance there's a gap in coverage that allows some issue to slip by, better safe than sorry. | 18:09 |
| ubottu | Pull 979 in canonical/cloud-init "Update ds-identify to pass shellcheck" [Open] | 18:09 |
| blackboxsw | akutz: yeah totally, we're thinking the same for the discussions you've had on making ds-identify bash and overhauling ds-id... it's high risk that we probably need to reflect to a broader discussion on cloud-init@lists.launchpad.net | 18:27 |
| blackboxsw | we can definitely continue to iterate on vmware work and PRs as I want to see us iron out what specifically can be done related to the netifaces dependencies your datasource needs. But that can wait until after this time-based upstream release as we don't want to surprise ourselves with some significant networking bugs while we try to grow support for cloud-init proper net utils/funcs/modules | 18:29 |
| blackboxsw | I like that at the moment the netifaces deps are scoped to just the new VMware datasource while you and your team get to run through testing/ci etc to make sure it performs as desired/expected. | 18:54 |
| blackboxsw | At some point after this upstream release, I'd like to chat next steps (probably on cloud-init mailinglist) about what approach we can take to meet your platform use-cases and OS support needs and how we can get cloud-init to grow proper/compliant network support if possible so other datasources can share in the same network discovery/representation etc. | 18:55 |
| blackboxsw | and that would be either by promoting netifaces to more global/common use, or instrumenting the gaps we have in current cloudinit.net module to meet the deficiencies you pointed on on your platform. | 18:56 |
| blackboxsw | again, that'd be a broad discussion that'd probably need more BSD,AlphineLinux,CentOS/SuSE and Ubuntu folks to chat about expectations there as overhauling the common network modules can be quite risky depending on what we are doing | 18:57 |
| blackboxsw | smoser: go4it on land/merge https://github.com/canonical/cloud-init/pull/978 if you have time | 18:59 |
| ubottu | Pull 978 in canonical/cloud-init "Revert unnecesary lcase in ds-identify" [Open] | 18:59 |
| blackboxsw | smoser: rharper falcojr we were hoping to cut a PR for release into ubuntu impish to get some bake time in on the VMware datasource stuff prior to getting to feature freeze. I think we have one more hotplug PR in flight for basic support. If you have anything that you'd really like to see in prior to a quick Impish release, just let us know | 19:00 |
| blackboxsw | akutz: ^ so also head up that Ubuntu impish 21.10 daily images will start containing VMware datasource a day after that "upload" completes. So if we get an upload in today, you could expect daily Ubuntu Impish cloudimages to contain your datasource early next week. | 19:02 |
| blackboxsw | if you are rolling your own images locally with tip of main for testing, then no big benefit for you. | 19:02 |
| blackboxsw | a note that this upload into Ubuntu impish will be 21.2.<somegithash> type release which would be the latest tip of upstream/main not the offical upstream release we plan on verifying and publishing next week | 19:03 |
| === blackboxsw changed the topic of #cloud-init to: 21.2 (May 6) | Next upstream release 21.3 (Aug 18th) | 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: Aug 17 17:15 UTC | ||
| akutz | Nice, thank you! | 19:12 |
| akutz | blackboxsw: The plans you mentioned for moving forward -- all sounds good. I will be rallying the maintainers of the VMware bits in the OVF DS as well. I think our primary use cases are around helping resource CI eventing and ensuring the instance data file has network information even when DHCP is used. | 19:13 |
| blackboxsw | +1 all this momentum your team is building is super helpful | 19:13 |
| akutz | Thanks! To be clear, the "team" in question is in another org from me. I'm the primary dev on the DS that was just merged, and only dev on it from VMware of which I'm aware. The issue is that it became more popular than the OVF transport. Now that there's a single VMware DS in CI, the team that manages the VMware bits from the OVF DS will be relocating them to the VMware DS. I do aim to ensure that things are cleaned up as they are moved into the DS | 19:16 |
| akutz | though as I worked hard to keep the DS as clean as possible. | 19:16 |
| blackboxsw | minimal: you mentioned hotplug and falcojr had you already peeked at https://github.com/canonical/cloud-init/pull/952 ? | 19:16 |
| ubottu | Pull 952 in canonical/cloud-init "Only invoke hotplug socket when functionality is enabled (SC-251)" [Open] | 19:16 |
| akutz | That said, that team and I do speak quite a bit, and I built consensus with them on this idea before moving ahead with it. So they're on the same page as me. | 19:17 |
| blackboxsw | minimal: as I *think* you said something about testing previously | 19:17 |
| blackboxsw | in your env | 19:17 |
| blackboxsw | akutz: great | 19:17 |
| akutz | As for making ds-identify bash -- I'm not actually for that. I just pointed out it would allow some enhanced pattern patching. The current issue is that you must assume the shell script is POSIX compliant only, even when it's likely dash or bash or zsh. | 19:18 |
| blackboxsw | ahh akutz on ds-id bash, My issue is a saw a tiny glimpse of the discussion (and didn't read in detail yet) but wondered if momentum was building that way. | 19:19 |
| akutz | blackboxsw: No worries. The tl;dr was we were trying to figure out the most optimal way to do three checks, each of which involved an RPC call and a need to test a string. I was trying to minimize the number of string tests due to forking to grep. But I realized that if we did that by testing the output of all three RPC calls at once inside a "{ RPC_FN1; RPC_FN2; RPC_FN3; } | grep PATT", the best case would be three rpc calls and one grep call. By | 19:22 |
| akutz | moving grep into the RPC functions, the best case is one RPC and one grep call. | 19:22 |
| akutz | I was annoyed at the inability to use string pattern matching because then the best case would be a single RPC call :) | 19:22 |
| blackboxsw | :) | 19:44 |
| blackboxsw | falcojr: https://github.com/canonical/cloud-init/pull/952 looks good. I'm testing now | 19:45 |
| ubottu | Pull 952 in canonical/cloud-init "Only invoke hotplug socket when functionality is enabled (SC-251)" [Open] | 19:45 |
| blackboxsw | falcojr: approved, rebased awaiting on CI https://github.com/canonical/cloud-init/pull/952 | 20:13 |
| ubottu | Pull 952 in canonical/cloud-init "Only invoke hotplug socket when functionality is enabled (SC-251)" [Open] | 20:13 |
| blackboxsw | then I **think** we can cut a tip of main release for upload into Impish | 20:14 |
| falcojr | sounds good to me! | 20:14 |
| minimal | blackboxsw: yeah I saw that PR. As currently only 3 DataSources support hotplug I'll have to read up on ConfigDrive to use it for local testing - I've only used NoCloud locally in the past. Thinking of using it with QEMU as I guess I can use QEMU's Monitor interface to add a 2nd network device on a running VM to see if the hotplug triggers | 20:36 |
| falcojr | blackboxsw: impish PR is here https://github.com/canonical/cloud-init/pull/981 | 20:40 |
| ubottu | Pull 981 in canonical/cloud-init "Ubuntu/devel" [Open] | 20:40 |
| blackboxsw | validating falcor | 21:10 |
| blackboxsw | just out of mtg. on it | 21:14 |
| blackboxsw | cloud-init 21.2-69 loooks to be uploaded into Ubuntu Impish (21.10). Expect it in daily cloudimages in a couple days. Here's the latest changelog https://paste.ubuntu.com/p/CQkPwJ23Y5/ | 21:51 |
| blackboxsw | confirmed: [ubuntu/impish-proposed] cloud-init 21.2-69-g65607405-0ubuntu1 (Accepted) | 21:52 |
| blackboxsw | so some hotplug support for OpenStack and Ec2 is testable in that Ubuntu impish upload as well as VMware datasource support | 21:52 |
| === blackboxsw is now known as blackboxsw_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!