[07:21] what's a nice way to serve cloud-init configuration? [07:22] put 'python3 -m http.server' in a unit file? === hjensas__ is now known as hjensas|lunch [13:42] can I get cloud-init to download a git repo and kick off a build? [13:52] How can I do the following with cloud-init: 1. Have a cloud-config session that does once-per-instance setup 2. A bash script that continues that once-per-instance setup, and 3. A bash-script that executes once-every-boot. I see in the docs how I could create a multipart mime which contains a cloud-config and 2 scripts, but not how to order them or to associate them with lifecycle. Thanks! [14:02] smoser, I'm reworking your code here: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/fix/1788915-vlan-sysconfig-rendering [14:02] smoser, should I add signed-off-by on the pull-request> [14:02] ? [14:09] https://github.com/canonical/cloud-init/pull/521#issuecomment-678476067 ⬅️ this the use-case scapy? for https://scapy.readthedocs.io/en/latest/introduction.html === hjensas|lunch is now known as hjensas [14:28] smoser, I'm gonna just leave a signed-off-by with your name, if you don't want it I can remove it. :) [14:29] morning, blackboxsw_ fyi the daily PPA builds for bionic/xenial are failing, https://launchpadlibrarian.net/494499147/buildlog.txt.gz https://launchpadlibrarian.net/494499148/buildlog.txt.gz [14:59] morning folks. [15:02] otubo: thats fine with me. [15:03] meena: we have a use-case for cloud-init to be able to do a dhcp request and read the response. [15:04] one path to that is through scapy (and a seemingly simple one) [15:04] but scapy's dependency stack is not small :-( [15:07] the difficulty we had wehn looking at a dhcp client in python is that all the example solutions do not use raw sockets. [15:07] and thus... have an ip address already. [15:07] s/have/assume/ === waxfire7 is now known as waxfire [15:10] @smoser scapy would also allow to do a lot of the network discovery work without heaps and heaps of guesswork [15:12] smoser: what makes scapy's dependency stack so big? i thought it only depends on libpcap? [15:13] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907235 [15:13] Debian bug 907235 in python3-scapy "python3-scapy: Please provide package without large 'Recommends'" [Normal,Fixed] [15:14] da fuck [15:14] that is fixed in debian (and i think in ubuntu as aresult), but not in all versions of ubuntu and not in many other os [15:14] who does that? why [15:17] the way new packages get into old versions of debuntu remains a mystery [15:31] Hi folks, so what's the current ETA for 20.3? [15:33] "when it's done" ;P [15:33] is anything ever done? ;-) [15:55] meena: they *don't* get into old versiosn of ubuntu. [15:55] by design. stable things are stable. [16:03] smoser: thanks for the review last week https://github.com/canonical/cloud-init/pull/543 in response. no longer handling non-decodable or non-gzipped content for user-data [16:06] ACK'd thanks [16:24] Hello all ... the docs give this example of combining a cloud-config and a bash script in a single mime multipart: % cloud-init devel make-mime -a config.yaml:cloud-config -a script.sh:x-shellscript > user-data [16:25] However, I'm not sure how that specifies the run order of cloud-config vs the shellscript, or how it specifies how often the shell script runs: per once, per instance, or per boot. Thanks! [17:19] x-shellscript run per-instance. [17:19] cloud-config is parsed before x-shellscript. [18:40] smoser: Thanks. So cloud-config runs before shell scripts no matter what. That's fine for me, and I'm guessing if that's a showstopped then run-cmd is your friend. Just checking. [18:41] smoser: what about … fixing broken packages in older versions of Debuntu? like when somebody accidentally made switched Recommends and Suggests? [18:42] runcmd runs ~shell-script time frame. [18:42] actually... odly based on filename. those actually (iirc) get thrown in a dir, and then run with rhnparts. and the runcmd script name is 'runCmd'. so its wierd. [18:43] As for 'x-shellscript run per-instance' ... I'm afraid I'm not sure what you mean. I do see in the code, that it looks like lifecycle gets controller by the /var/lib/cloud/per-[once|instance|boot] folders, but I'm not sure how to use cloud-init to populate those folders. Thanks! [18:43] meena: it all kind of depends. [18:43] * meena is a big fan of "if broken it is, fix it you should" [18:43] if you really reallly wanted to get that change in, you have to convince someone on the SRU team that it is important enough. [18:44] i tend to be a fan of keeping behavior the same. [18:44] as the primary value of a platform is to put things on top of. its harder to build on a platform if the platform is changing. [18:44] thus.... the value of a "stable platform" is almost *entirely* the stability [18:45] but... its not me that has to be convinced, and, while ubuntu has guidelines on such things, they're not always 100% consistently applied. [18:45] smoser: well, yes, but the behaviour did change, no? [18:46] it changed from one stable platform to the next. and thats fine. when yo u start to move your house to that next stable platform, then you deal with it. [18:47] i dont remember the exact values here, but lets just say: [18:47] 16.04: little recommends [18:47] 18.04: big recommends [18:47] 20.04: little recommends [18:48] thats perfectly fine. it sucks that 18.04 is got this wart there, but people that are building on it expect the wart. [18:49] aye. [18:49] but again... these are *my* feelings towards that sort of thing. the person who decides is a Stable Release Team member, and (in my experience) their individual opinions and behaviors differ. [18:49] but yeah, i agree that having a dedicated python3-scapy only package without the kitchensink would be preferable… which of course won't be backported, eh? [18:49] and sometimes even differ based on the time. [18:50] the are humans, and as a result have a very hard time remaining consistent. [18:50] largely RHEL and SuSE have simmilar processes/values [18:50] some people make horrible decisions if they didn't have breakfast, or if their underpants are too tight. [18:52] so to depend on scapy, i think for the near term, the thing we have to do is make it optional, with a fallback to the questionable decision that I made some years ago to use dhclient like we do [18:52] (see.... consistency hard for people!) [18:59] smoser: see, if you had gone with scapy years ago, you could've kept it from balooning in size in certain versions of debuntu… and we'd… have a very different networking refactor on our hands rn ;) [19:10] minimal: meena sorry, didn't open this up yet today. We're waiting on one final PR and will start the release/SRU processes. falcojr has the PR up but needs review/etc so hopefully that goes through today and we'll start the release tomorrow. [19:11] rick_h: oh, so it *is* an SRU release [19:11] also, i forgot what that means again [19:14] stable release upgrade, the exception to the don't update stable releases [19:15] for cloud-init we take the latest upstream code, push it to the devel release and then test it against the supported releases [19:15] in this case xenial, bionic, and focal [19:22] smoser: I am quite confused ... but as best as I can tell: I can add bash scripts to my multi-part mime, and they will be run once per instance, unless I override scripts-user in my cloud-config to [scripts-user, always], in which case my bash scripts will execute on boot. [19:22] As for my wanting to have one script execute per-instance, and one execute per-boot ... it looks like I could only achieve that by manually copying files to the /var/lib/cloud/per-boot and -instance folders. There's no way to do that otherwise. Is that all correct? [19:29] beantaxi_: I suggest that you you use write_files and then emit them into the different scripts-per frequency desired, /var/lib/cloud/scripts/per-{boot,instance,once} ; [19:29] yeah. [19:31] it does seem useful to have a way to put those in user-data. but as it is, writing files to /var/lib/cloud/per-boot is the only real way. [19:36] Ah, so in a pinch write_files can be used to put whatever files I want, wherever I want them. That's useful. [19:42] Would it be technically possible to implement something a bit more like I'm describing, by eg allowing an optional header for a dest folder (or more indirectly specifying a 'per [19:43] ')? Or is the mime-parsing code handled by the cloud providers rather than by cloud-init [19:43] by cloud-init [19:43] we could absolutely improve cloud-init to do what you're after. [19:44] I'm happy to take a lame swing at it ... but I'd want to make sure I'd set expectations sufficiently low [19:46] In my specific use case, I have a little family of VM initialization scripts, where each VM has an init-image and an init-vm script. Naturally I found out about cloud-init about 5 minutes after I was done. [19:46] https://cloudinit.readthedocs.io/en/latest/topics/format.html#part-handler [19:47] you could use a part-handler to do what youre after. [19:47] So I'd like to use the scripts as-is -- where init-image is per-isntance and init-vm is per-boot, and also start transitioning my per-instance stuff to cloud-config, which I am sure over time I will prefer. [19:47] Ok nice. I was not quite sure what those were for. [19:48] K, this is making total sense [19:49] The part-handler docs link to a blog post from 2011 from 'Foss Boss'. Is this info likely still current? [19:58] falcojr: did you have an azure instance up that exhibits https://github.com/canonical/cloud-init/pull/539? [19:58] * blackboxsw_ is trying to get that review complete so we can cut 20.3 [20:36] blackboxsw_ bah, sorry, didn't get the notification [20:36] I have one with the fix currently [20:36] I could spin one up quickly that shows the problem though [20:36] it just needs to have accelerated networking (on the network tab if you're in the UI) [20:37] I used a focal DS2 v2 instance [20:38] s/focal/bionic [20:46] +1 I'll launch an instance. were you using amazon linux or ubuntu? [20:47] O.o amazon linux on azure? [20:47] hahah [20:47] oops brain fail [20:47] probably not a product that azure is currently selling :) [20:48] :D [20:50] haha, it should happen on focal or bionic. I used bionic [21:00] falcojr: strange as I've added accelerated networking on a DS2v2 instance and not seeing the delay on bionic [21:00] ubuntu@test-b1:~$ systemd-analyze blame [21:00] 8.553s cloud-init.service [21:00] 8.553s cloud-init.service [21:00] 6.857s cloud-init-local.service [21:07] did you reboot? [21:07] blackboxsw_ ^ [21:08] it doesn't happen on first boot [21:48] falcojr: rebooting now. sure enough 1min 31.262s cloud-init-local.service [21:48] thanks [21:49] blackboxsw_: if you're one a box now, I just posted some questions on that PR; would be nice to see requested info attached to the bug that PR addresses; [21:49] +1 rharper [21:50] I'm also seeing the type of failure mode I think we were looking for on current bionic images, like a failed "rename3" interface lying around post reboot [21:50] with matching mac addr [21:51] yeah, I'm super interested to confirm whether there are two hv_net nics, or if there's a different sriov driver name (we already blacklist the mlx4_core) [22:00] blackboxsw_: I wonder if we just dropped including the driver value in the emitted netplan [22:00] rharper: checking now. we only blacklist mlx4_core on fallback network right? [22:00] on azure [22:00] yeah [22:01] * blackboxsw_ double checks [22:01] that can't be right [22:01] also responded first here: https://github.com/canonical/cloud-init/pull/539#discussion_r475918457 [22:01] * blackboxsw_ tries to recall how to attach binary (cloud-init.logs.tar.gz) to github comments [22:01] if that's even possible [22:02] you can attach to the bug it references [22:02] mlx5_core [22:03] looks like we'll need to blacklist both 4 and 5 (and fix non-fallback path to include drivers) [22:03] do we know if IMDS reports the sriov interface at all ? [22:15] checking [22:16] rharper: nope ... http://paste.ubuntu.com/p/CFjtY7JHm4/ [22:16] well "yes" in that it only reports one interface [22:17] yeah, I don't think it did [22:17] and both share the the same mac [22:17] :) [22:17] yeah [22:17] I recall asking in the past [22:19] blackboxsw_: I replied; I think the fix is good; but let's update the commit message; the issue here is that once we started rendering from IMDS, we regressed Accelerated Networking setups due to not including the hv_netsvc driver name in our match; when we were v1 rendering, that emits a udev rule which matches the MAC and DRIVER != $blacklist ; [22:19] the fix for netplan is what's there (binding the emitted netplan to the hyperv driver nic) [22:20] on the fallback path, we need both mlx4 and mlx5 core (xenial running on AdvNet instances with mxl5 will likely have this hang as well ) [22:20] rharper: adding https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1830740/comments/11 while I look at this [22:20] Ubuntu bug 1830740 in linux-azure (Ubuntu) "[linux-azure] Delay during boot of some instance sizes" [Undecided,New] [22:21] I wonder if sysconfig rendered instances see failures, depends on what the udev rules look like [22:21] cool [22:22] why wouldn't we want to just blacklist on the mlx* IMDS-based network config [22:22] and on fallback config [22:30] ok confirmed eth0 is driver/module: module -> ../../../../module/hv_netvsc rename3 : module -> ../../../../module/mlx5_core [22:30] so yeah, just wondering if maybe we should make sure we blacklist both mlx5_core and mlx4_core in both fallback config and imds-based config we write [22:31] so we don't unintentially ignore other device types. [22:32] or are there any other device types that would present "hv_netvsc" for one interface and bool(not any(['mlx4_core', 'mlx5_core'])) [22:32] guess that's a question for both falcojr and rharper [22:33] blackboxsw_: so blacklist only works for eni and sysconfig which emit udev rules [22:33] ohhh doh [22:33] for netplan, the 50-cloud-init.yaml needs to use the match driver=hv [22:33] with the mac [22:33] ok ok, so drive matching is the inverse approach for netplan [22:33] driver* matching [22:34] we know (for now) that any rendered interface in IMDS on Azure is hv_ [22:34] blackboxsw_: well, we could emit a driver != I think ... let me confirm [22:35] yeah, we could emit: Driver=!mlx4_core\nDriver=!=mlx5_core [22:35] however, I'm not sure if netplan likes that ... [22:37] right, or it it only honors the latter of the settings etc [22:38] * blackboxsw_ tries a generate [22:38] and sees what systemd thinks [22:38] quoted it accepts the !driver [22:38] but not sure about a list (or multiple [22:38] I suppose we won't have both [22:38] well, that's not easily found [22:38] without finding the dup mac device (which may not be present) [22:39] I think the current code is safest [22:43] yeah I think so too at the moment, trying a clean and dirty upgrade and reboot with new code now [22:44] as the duplicate !driver matches may collide in systemd or netplan cfg with unintentional side-effects (or matching nothing) [22:44] like OR instead of AND [22:49] falcojr: at the moment, I'm still seeing 90 seconds times on reboot even with driver matching hv_netvsc [22:49] on dirty cloud-init upgrade/reboot [22:49] http://paste.ubuntu.com/p/7NjWHX2QTY/ [22:51] interesting but 2nd reboot was fixed. [23:03] I didn't see it after a clean and reboot