[07:21] <makara1> what's a nice way to serve cloud-init configuration?
[07:22] <makara1> put 'python3 -m http.server' in a unit file?
[13:42] <makara1> can I get cloud-init to download a git repo and kick off a build?
[13:52] <beantaxi> 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] <otubo> 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] <otubo> smoser, should I add signed-off-by on the pull-request>
[14:02] <otubo> ?
[14:09] <meena> https://github.com/canonical/cloud-init/pull/521#issuecomment-678476067 ⬅️  this the use-case scapy? for https://scapy.readthedocs.io/en/latest/introduction.html
[14:28] <otubo> 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] <rharper> 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] <blackboxsw_> morning folks.
[15:02] <smoser> otubo: thats fine with me.
[15:03] <smoser> meena: we have a use-case for cloud-init to be able to do a dhcp request and read the response.
[15:04] <smoser> one path to that is through scapy (and a seemingly simple one)
[15:04] <smoser> but scapy's dependency stack is not small :-(
[15:07] <smoser> 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] <smoser> and thus... have an ip address already.
[15:07] <smoser> s/have/assume/
[15:10] <meena> @smoser scapy would also allow to do a lot of the network discovery work without heaps and heaps of guesswork
[15:12] <meena> smoser: what makes scapy's dependency stack so big? i thought it only depends on libpcap?
[15:13] <smoser> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907235
[15:14] <meena> da fuck
[15:14] <smoser> 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] <meena> who does that? why
[15:17] <meena> the way new packages get into old versions of debuntu remains a mystery
[15:31] <minimal> Hi folks, so what's the current ETA for 20.3?
[15:33] <meena> "when it's done" ;P
[15:33] <minimal> is anything ever done? ;-)
[15:55] <smoser> meena: they *don't* get into old versiosn of ubuntu.
[15:55] <smoser> by design. stable things are stable.
[16:03] <blackboxsw_> 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] <smoser> ACK'd thanks
[16:24] <beantaxi_> 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] <beantaxi_> 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] <smoser> x-shellscript run per-instance.
[17:19] <smoser> cloud-config is parsed before x-shellscript.
[18:40] <beantaxi_> 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] <meena> smoser: what about … fixing broken packages in older versions of Debuntu? like when somebody accidentally made switched Recommends and Suggests?
[18:42] <smoser> runcmd runs ~shell-script time frame.
[18:42] <smoser> 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] <beantaxi_> 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] <smoser> meena: it all kind of depends.
[18:43]  * meena is a big fan of "if broken it is, fix it you should"
[18:43] <smoser> 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] <smoser> i tend to be a fan of keeping behavior the same.
[18:44] <smoser> 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] <smoser> thus.... the value of a "stable platform" is almost *entirely* the stability
[18:45] <smoser> 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] <meena> smoser: well, yes, but the behaviour did change, no?
[18:46] <smoser> 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] <smoser> i dont remember the exact values here, but lets just say:
[18:47] <smoser>  16.04: little recommends
[18:47] <smoser>  18.04: big recommends
[18:47] <smoser>  20.04: little recommends
[18:48] <smoser> 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] <meena> aye.
[18:49] <smoser> 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] <meena> 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] <smoser> and sometimes even differ based on the time.
[18:50] <smoser> the are humans, and as a result have a very hard time remaining consistent.
[18:50] <smoser> largely RHEL and SuSE have simmilar processes/values
[18:50] <meena> some people make horrible decisions if they didn't have breakfast, or if their underpants are too tight.
[18:52] <smoser> 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] <smoser> (see.... consistency  hard for people!)
[18:59] <meena> 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] <rick_h> 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] <meena> rick_h: oh, so it *is* an SRU release
[19:11] <meena> also, i forgot what that means again
[19:14] <powersj> stable release upgrade, the exception to the don't update stable releases
[19:15] <powersj> 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] <powersj> in this case xenial, bionic, and focal
[19:22] <beantaxi_> 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] <beantaxi_> 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] <rharper> 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] <smoser> yeah.
[19:31] <smoser> 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] <beantaxi_> 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] <beantaxi_> 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] <beantaxi_> ')? Or is the mime-parsing code handled by the cloud providers rather than by cloud-init
[19:43] <smoser> by cloud-init
[19:43] <smoser> we could absolutely improve cloud-init to do what you're after.
[19:44] <beantaxi_> 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] <beantaxi_> 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] <smoser> https://cloudinit.readthedocs.io/en/latest/topics/format.html#part-handler
[19:47] <smoser> you could use a part-handler to do what youre after.
[19:47] <beantaxi_> 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] <beantaxi_> Ok nice. I was not quite sure what those were for.
[19:48] <beantaxi_> K, this is making total sense
[19:49] <beantaxi_> The part-handler docs link to a blog post from 2011 from 'Foss Boss'. Is this info likely still current?
[19:58] <blackboxsw_> 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] <falcojr> blackboxsw_ bah, sorry, didn't get the notification
[20:36] <falcojr> I have one with the fix currently
[20:36] <falcojr> I could spin one up quickly that shows the problem though
[20:36] <falcojr> it just needs to have accelerated networking (on the network tab if you're in the UI)
[20:37] <falcojr> I used a focal DS2 v2 instance
[20:38] <falcojr> s/focal/bionic
[20:46] <blackboxsw_> +1 I'll launch an instance. were you using amazon linux or ubuntu?
[20:47] <powersj> O.o amazon linux on azure?
[20:47] <blackboxsw_> hahah
[20:47] <blackboxsw_> oops brain fail
[20:47] <blackboxsw_> probably not a product that azure is currently selling :)
[20:48] <powersj> :D
[20:50] <falcojr> haha, it should happen on focal or bionic. I used bionic
[21:00] <blackboxsw_> falcojr: strange as I've added accelerated networking on a DS2v2 instance and not seeing the delay on bionic
[21:00] <blackboxsw_> ubuntu@test-b1:~$ systemd-analyze blame
[21:00] <blackboxsw_>           8.553s cloud-init.service
[21:00] <blackboxsw_>           8.553s cloud-init.service
[21:00] <blackboxsw_>           6.857s cloud-init-local.service
[21:07] <falcojr> did you reboot?
[21:07] <falcojr> blackboxsw_ ^
[21:08] <falcojr> it doesn't happen on first boot
[21:48] <blackboxsw_> falcojr: rebooting now. sure enough     1min 31.262s cloud-init-local.service
[21:48] <blackboxsw_> thanks
[21:49] <rharper> 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] <blackboxsw_> +1 rharper
[21:50] <blackboxsw_> 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] <blackboxsw_> with matching mac addr
[21:51] <rharper> 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] <rharper> blackboxsw_: I wonder if we just dropped including the driver value in the emitted netplan
[22:00] <blackboxsw_> rharper: checking now. we only blacklist mlx4_core on fallback network right?
[22:00] <blackboxsw_> on azure
[22:00] <rharper> yeah
[22:01]  * blackboxsw_ double checks
[22:01] <rharper> that can't be right
[22:01] <blackboxsw_> 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] <blackboxsw_> if that's even possible
[22:02] <rharper> you can attach to the bug it references
[22:02] <rharper> mlx5_core
[22:03] <rharper> looks like we'll need to blacklist both 4 and 5 (and fix non-fallback path to include drivers)
[22:03] <rharper> do we know if IMDS reports the sriov interface at all ?
[22:15] <blackboxsw_> checking
[22:16] <blackboxsw_> rharper: nope ... http://paste.ubuntu.com/p/CFjtY7JHm4/
[22:16] <blackboxsw_> well "yes" in that it only reports one interface
[22:17] <rharper> yeah, I don't think it did
[22:17] <blackboxsw_> and both share the the same mac
[22:17] <blackboxsw_> :)
[22:17] <blackboxsw_> yeah
[22:17] <rharper> I recall asking in the past
[22:19] <rharper> 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] <rharper> the fix for netplan is what's there (binding the emitted netplan to the hyperv driver nic)
[22:20] <rharper> 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] <blackboxsw_> rharper: adding https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1830740/comments/11 while I look at this
[22:21] <rharper> I wonder if sysconfig rendered instances see failures, depends on what the udev rules look like
[22:21] <rharper> cool
[22:22] <blackboxsw_> why wouldn't we want to just blacklist on the mlx* IMDS-based network config
[22:22] <blackboxsw_> and on fallback config
[22:30] <blackboxsw_> ok confirmed eth0 is driver/module: module -> ../../../../module/hv_netvsc     rename3 :   module -> ../../../../module/mlx5_core
[22:30] <blackboxsw_> 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] <blackboxsw_> so we don't unintentially ignore other device types.
[22:32] <blackboxsw_> 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] <blackboxsw_> guess that's a question for both falcojr and rharper
[22:33] <rharper> blackboxsw_: so blacklist only works for eni and sysconfig which emit udev rules
[22:33] <blackboxsw_> ohhh doh
[22:33] <rharper> for netplan, the 50-cloud-init.yaml needs to use the match driver=hv
[22:33] <rharper> with the mac
[22:33] <blackboxsw_> ok ok, so drive matching is the inverse approach for netplan
[22:33] <blackboxsw_> driver* matching
[22:34] <rharper> we know (for now) that any rendered interface in IMDS on Azure is hv_
[22:34] <rharper> blackboxsw_: well, we could emit a driver != I think ... let me confirm
[22:35] <rharper> yeah, we could emit:  Driver=!mlx4_core\nDriver=!=mlx5_core
[22:35] <rharper> however, I'm not sure if netplan likes that ...
[22:37] <blackboxsw_> right, or it it only honors the latter of the settings etc
[22:38]  * blackboxsw_ tries a generate 
[22:38] <blackboxsw_> and sees what systemd thinks
[22:38] <rharper> quoted it accepts the !driver
[22:38] <rharper> but not sure about a list (or multiple
[22:38] <rharper> I suppose we won't have both
[22:38] <rharper> well, that's not easily found
[22:38] <rharper> without finding the dup mac device (which may not be present)
[22:39] <rharper> I think the current code is safest
[22:43] <blackboxsw_> yeah I think so too at the moment, trying a clean and dirty upgrade and reboot with new code now
[22:44] <blackboxsw_> as the duplicate !driver matches may collide in systemd or netplan cfg with unintentional side-effects (or matching nothing)
[22:44] <blackboxsw_> like OR instead of AND
[22:49] <blackboxsw_> falcojr: at the moment, I'm still seeing 90 seconds times on reboot even with driver matching hv_netvsc
[22:49] <blackboxsw_> on dirty cloud-init upgrade/reboot
[22:49] <blackboxsw_> http://paste.ubuntu.com/p/7NjWHX2QTY/
[22:51] <blackboxsw_> interesting but 2nd reboot was fixed.
[23:03] <falcojr> I didn't see it after a clean and reboot