19:00:56 <rvandegrift> #startmeeting
19:00:56 <MeetBot> Meeting started Wed Sep  9 19:00:56 2020 UTC.  The chair is rvandegrift. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:45 * noahm waves
19:01:51 <rvandegrift> after the cloud BoF, we said we'd talk about doing jitsi meetings.  I thought it'd also be good to see if we wanted to try a remote sprint this fall.  does anyone have other topics?
19:02:31 <noahm> I'm happy to try jitsi. Only issue is the lack of meetbot there.
19:03:32 <waldi> well, we would need to take notes, like during an in person meeting
19:03:57 <noahm> Everybody's favorite task ;)
19:04:22 <waldi> sure
19:05:07 <noahm> I'm also in favor of a remote sprint, but I think it'd be important to come up with an agenda ahead of time. We'll need to schedule across a lot of different timezones and we need to make sure the time is used effectively.
19:05:32 <rvandegrift> I'll volunteer to write minutes next meeting and we'll try jitsi instead of irc
19:05:42 <noahm> works for me. thanks.
19:06:25 <rvandegrift> agreed, a remote sprint seems harder.  an agenda would be useful.  I also don't know if doing all day sessions is reasonable via video chat
19:06:36 <noahm> yeah
19:07:42 <noahm> Maybe we can all put some though into sprint activities, and propose agenda ideas over the next few weeks. Discuss them at the next meeting, and put together a schedule based on that.
19:08:02 <rvandegrift> good idea - I'll send a note to the mailing list since it looks like most folks couldn't make it today
19:08:15 <noahm> awesome.
19:09:07 <rvandegrift> that's all I had on this stuff.  Other topics?
19:09:31 <noahm> I wouldn't mind a short discussion on publishing images with buster-backports kernels.
19:09:43 <rvandegrift> sure
19:10:43 <waldi> sadly i don't have any numbers on the usage in azure. i know numbers exist somewhere
19:11:00 <noahm> we do publish backports kernel images there, right?
19:11:09 <noahm> Are they as visible as the standard images?
19:11:12 <waldi> yes
19:11:36 <noahm> I have a couple merge requests open with the kernel team for AWS related things, but I'm not sure they'll want to merge them.
19:12:00 <noahm> ^^^ targeting the buster kernel.
19:12:24 <noahm> If they decide not to merge them, then the functionality will require a newer kernel.
19:13:26 <noahm> So, publishing arm64 and amd64 images with the backports kernel seems like a possible approach.
19:14:02 <noahm> Are there any strong objections to this?
19:14:15 <rvandegrift> no, sounds reasonable to me
19:14:33 <waldi> nope
19:14:51 <noahm> The lack of security support is unfortunate, but I don't know what other choices we have.
19:15:19 <rvandegrift> I guess we'll need another marketplace listing for that too?
19:15:26 <waldi> support by the security team. the upstream kernel is security supported by … upstream
19:16:15 <noahm> waldi: yes, and benh is good about updating the backports kernel, but it's still not done as frequently as upstream publishes security fixes.
19:16:29 <noahm> rvandegrift: yeah
19:16:38 <waldi> hmpf. if you select debian 10 on azure, you get the backports variant pre-selected currently. i asked them not to do that several times
19:17:17 <noahm> huh, that doesn't seem ideal.
19:18:00 <waldi> well. in that case it's a first party image. so the microsoft support get's the first bunch on angry questions
19:18:24 <rvandegrift> I bet that means it's quite popular :)
19:18:41 <waldi> i have no idea
19:18:55 <noahm> OK, so I'll continue trying to get my MRs into the buster kernel, but will also prepare for eventually publishing backports kernel images. That'll probably happen at some point, regardless of what happens with the current MRs.
19:19:32 <noahm> In particular, right now we fail to boot on the arm64 bare-metal EC2 instance types, which is bad.
19:20:19 <waldi> *shrug* i didn't even know such things exists
19:21:45 <noahm> They're pretty awesome. 64 arm64 cores, lots of RAM, fast local nvme storage.
19:22:57 <rvandegrift> yea sounds like it'd be nice to have that working
19:23:21 <noahm> Anyway, that's enough for this topic.
19:23:33 <rvandegrift> anything else?
19:23:34 <waldi> (my current kernel building instance got 64 x86 cores and 256GB ram or so)
19:23:39 <waldi> yes
19:23:46 <noahm> waldi: do you have anything new to say about the systemd-networkd investigation?
19:24:01 <waldi> i got asked if we could expedite point release updates
19:24:20 <waldi> not exactly sure why, but i thought about it
19:24:40 <rvandegrift> are they delayed for a long time now?
19:25:07 <waldi> we might anyway want to build images including packages from proposed-updates to maybe in the future find problems before the release
19:25:24 <waldi> but this means we need to split buster (with proposed-updates) and buster (with security)
19:25:57 <rvandegrift> yea, sounds like it could be useful
19:26:02 <noahm> Yeah, I have thought of that before. I think it makes sense.
19:26:16 <waldi> they are delayed few days, because they automatic build will first build one the next morning and then someone needs to manualy trigger the release process
19:27:09 <waldi> if we build images with proposed-updates, we can just release an image that was build somewhere after the freeze, as long as no packages have been excluded from the point release
19:27:42 <noahm> So we'd need to pay a little closer attention to the actual details of the point release
19:27:47 <waldi> yep
19:28:51 <noahm> It'd be nice to automate some checks around that. I wouldn't want to release something that was excluded from the release.
19:28:52 <waldi> we might be able to slip a point into the check list
19:29:31 <waldi> yep. should be easy
19:29:45 <rvandegrift> wouldn't that leave proposed-updates in the apt sources for the point release?
19:29:48 <waldi> no
19:30:01 <waldi> we replace the whole sources.list in the end
19:30:06 <noahm> no, we have the _BUILD classes that provide different sources during the build
19:30:10 <noahm> So we are safe there
19:31:08 <rvandegrift> oh I see
19:32:13 <noahm> waldi: are you planning on working on this in the near future? Or should someone else pick it up?
19:32:37 <waldi> someone else could pick that up
19:33:09 <noahm> I will create an issue on salsa so we can track it there.
19:33:23 <waldi> thx
19:35:57 <rvandegrift> if there's nothing else, then I think we're finished for this month
19:36:09 <waldi> noahm asked about systemd-networkd
19:36:17 <waldi> i actually looked into it a bit
19:36:18 <rvandegrift> oh I missed that, sorry!
19:36:41 <waldi> the whole ipv4+ipv6 dhcp stuff works nicely
19:37:06 <waldi> i realized that azure seems to have started to always assign ipv6 addresses to instances
19:37:27 <waldi> multi-nic is a problem
19:37:52 <waldi> it somehow takes about 2s longer to boot
19:38:00 <waldi> not sure why yet
19:38:45 <noahm> huh. Do you have a debian-cloud-images branch that configures an image with networkd? I'd be very interested in looking at it.
19:38:53 <waldi> sure
19:39:14 <waldi> https://salsa.debian.org/waldi/debian-cloud-images/-/tree/test-systemd-networkd
19:39:33 <noahm> thanks
19:41:10 <waldi> cloud-init currently hard depends on ifupdown, that's why it tries realy hard to kill it
19:42:00 <noahm> right, it'll take some work if we want to change that.
19:42:31 <waldi> i have not found a way to do dynamic policy routing. systemd-networkd can configure that, but only static
19:42:45 <noahm> As long as ifupdown remains Debian's default, I wonder how hard we want to push in this direction.
19:43:20 <noahm> ifupdown and dhclient may not be pretty, but they're very flexible.
19:43:27 <waldi> ifupdown is not debian's default. network-manager is used by d-i with desktop environment
19:43:48 <noahm> if there's no desktop environment?
19:43:52 <waldi> yeah. i don't know yet
19:45:37 <waldi> systemd-networkd at least solves some problems, but is less flexible for sure
19:46:29 <rvandegrift> https://gitlab.com/craftyguy/networkd-dispatcher provides some hooks for more flexibility, though I haven't actually used it before
19:47:44 <waldi> hmm
19:47:49 <noahm> that's potentially interesting. it looks like it's trying to implement some of the extensibility that dhclient provides.
19:51:28 <waldi> davdunc still didn't manage to handle those AWS accounts?
19:51:49 <noahm> not so far as I've heard... will nag again.
19:52:36 <noahm> oh, not sure if anybody noticed this, but Amazon Lightsail added buster, finally.
19:53:02 <noahm> They still have jesse, which really needs to go away. I have informed them of this.
19:55:54 <noahm> I have no other topics.
19:55:57 <waldi> did our dpl contact anyone from the cloud team, which is currently tasked to handle vendor relations, with his "debian.net team" idea?
19:56:40 <waldi> because what he brought up in -project includes another team tasked with cloud vendor relations
19:56:51 <noahm> presumably it would be one of the delegates he'd have contacted?
19:57:40 <noahm> I haven't heard anything from him besides what was on -project.
19:57:53 <rvandegrift> I didn't see anything other than the -project thread
19:57:59 <waldi> okay
19:58:18 <waldi> i don't have anything else
19:58:37 <rvandegrift> okay folks - thanks for the time!
19:58:43 <rvandegrift> #endmeeting