18:59:31 <rvandegrift> #startmeeting
18:59:31 <MeetBot> Meeting started Wed Jul  8 18:59:31 2020 UTC.  The chair is rvandegrift. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:53 <rvandegrift> do we have topics for today's discussion?
18:59:57 <noahm> greetings
19:00:02 <chillysurfer> hey, all
19:00:36 <noahm> for those who haven't been following along, we should be getting cloud-init 20.2 in the next buster point release.
19:00:46 <chillysurfer> oh nice
19:00:49 <chillysurfer> so no blockers?
19:01:15 <rvandegrift> yea that's great news, thanks for the work on that
19:01:17 <noahm> nope; the release managers have approved it and I uploaded, so everything is queued up for release
19:01:28 <chillysurfer> awesome, really great to hear that
19:01:45 <Mrfai> good news, that this works so easily
19:02:41 <noahm> beyond that, a few packages have transitioned to the cloud team. awscli and the python-boto (and botocore) packages. So potentially we can get them updated in stable in the future.
19:03:27 <noahm> https://wiki.ubuntu.com/CloudinitUpdates is ubuntu's process for updating cloud-init in stable releases. I think we'll want to follow something similar for our cloud packages in stable.
19:03:33 <rvandegrift> #info stable update uploaded for cloud-init, other cloud-relevant modules have been adopted by us for possible future updates
19:04:59 <noahm> Did anybody submit anything for the DebConf CFP?
19:05:09 <noahm> IIRC somebody scheduled a BoF
19:05:51 <rvandegrift> yea, zigo did but I haven't followed up since his email
19:06:52 <noahm> I was hoping to do a more structured presentation on cloud stuff, but I never really came up with a specific topic so I didn't submit anything.
19:08:53 <rvandegrift> I made some progress recently on live image test, but ran into a salsa limitation that prevents me from running it in gitlab-ci.  Working on a solution, will discuss with salsa maintainers once I have something concrete
19:10:37 <Mrfai> I like to have checksums for our images. On /cdimage.debian.org/images/cloud/ we say we have them, but that's only true of the openstack images build by the old tool.
19:11:06 <Mrfai> IMO openstack users want them, but there are still not available
19:11:44 <Mrfai> sadly I cannot help, because I have no pyhthon skills
19:11:49 <rvandegrift> yea - I haven't had time to test waldi's last round of fixes, but it's on my list
19:12:14 <rvandegrift> #action rvandegrift follow up on image checksum mr
19:12:30 <noahm> this MR, specifically? https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203
19:13:00 <rvandegrift> yep
19:13:37 <Mrfai> and issues/15 is related
19:14:36 <noahm> So that just needs more reviews, etc?
19:14:57 <Mrfai> I guess so.
19:15:30 <noahm> I'll try to spend some time on that.
19:15:42 <rvandegrift> I tested a previous version and ran into an issue, mostly I want to check that its working for me
19:16:01 <Mrfai> Other MRs or issues we should talk about here?
19:16:20 <noahm> on a different topic, I have packaged amazon-ec2-utils, which is sitting in NEW right now. But there's also https://github.com/systemd/systemd/issues/11532, which might obviate it.
19:16:49 <noahm> I don't know if anybody wants to speak up on that github issue, which seems to have stagnated despite maintainer support
19:17:33 <Mrfai> which github issue?
19:17:39 <noahm> https://github.com/systemd/systemd/issues/11532
19:18:43 <noahm> There are some udev rules that are useful on EC2. I don't know if there are others for Azure or OpenStack or whatever. We could either put them in individual packages like amazon-ec2-utils, or work to get them directly into systemd.
19:19:40 <Mrfai> Isn't the easiest way to put those udev rules in our config space?
19:20:41 <Mrfai> So we maintain them until they are upstream in some package.
19:20:59 <Mrfai> But our users can benefit from them now.
19:21:00 <noahm> It's certainly _easiest_, but I think it's desirable to have files on disk owned by packages if possible.  (not that we do that universally right now, but it'd be nice not to deviate further)
19:21:35 <chillysurfer> is this for any specific udev rules, or just as a general move?
19:22:01 <noahm> Yeah... In EC2's case, the udev rules depend on a helper program (python) that inspects various NVME variables.
19:22:22 <chillysurfer> ok got it
19:23:01 <noahm> https://salsa.debian.org/cloud-team/amazon-ec2-utils/-/blob/master/ebsnvme-id is the helper program.
19:23:27 <noahm> And https://salsa.debian.org/cloud-team/amazon-ec2-utils/-/blob/master/70-ec2-nvme-devices.rules is the udev file
19:23:42 <Mrfai> If you think it's easy to put them into amazon-ec2-utils, got for it. I would not wait until they are in systemd.
19:24:09 <Mrfai> Ah they are already ther
19:24:14 <Mrfai> there
19:24:25 <noahm> I guess we can always drop amazon-ec2-utils if systemd ever incorporates the files.
19:25:14 <noahm> I (both with my AWS hat on and my Debian hat on) may chime in on the systemd issue. Do any other clouds have any similar udev rules that are worth adding to systemd?
19:25:36 <noahm> If so, it might be worth saying something on the issue
19:26:26 <Mrfai> would be good so get some feedback now, even it's a no need for thi in cloud enviroment X
19:26:34 <Mrfai> this
19:27:01 <chillysurfer> there is a udev rule i've had to create for our usecase to have systemd manage our hypervisor device
19:27:08 <Mrfai> any folks from azure, gce can comment on this?
19:27:10 <chillysurfer> but i'm not sure if it makes sense to live in systemd
19:27:21 <chillysurfer> (i'm from azure by the way)
19:27:39 <noahm> would you incorporate it into some other package?
19:27:43 * kuLa is late sorry, carching up
19:27:56 <chillysurfer> i would think the more natural place for this udev rule is in the hyperv-daemons pkg
19:28:18 <chillysurfer> (totally understanding this is a very specific udev rule, but it's the only one that comes to mind for azure at the moment)
19:28:54 <Mrfai> chillysurfer: if this rules makes sense for the user, add it to the package.
19:29:20 <chillysurfer> yeah i think that's the best approach for this particular rule
19:29:34 <chillysurfer> i don't have any other udev rules on mind for azure but i can think offline
19:29:45 <Mrfai> What about GCE?
19:30:06 <noahm> GCE builds their own images, so they can kind of do whatever they want.
19:30:41 <rvandegrift> chillysurfer are the udev rules the same on all distros?  if so, systemd might provider wider benefits
19:30:47 <noahm> chillysurfer: systemd upstream seems ammenable to having these rules in their repo, so it's worth at least mentioning them there. If they end up not being appropriate for inclusion, that's fine.
19:30:55 <noahm> rvandegrift: +1
19:31:00 <chillysurfer> rvandegrift: yes this is for all distros
19:31:16 <chillysurfer> ok so maybe having them in systemd is the right approach then
19:31:35 <rvandegrift> yea, seems worth pursing
19:32:11 <chillysurfer> sounds good, will do
19:32:21 <chillysurfer> noahm: you're going to just stack onto that github issue then?
19:32:34 <noahm> yeah
19:32:40 <chillysurfer> ok i'll follow then
19:33:12 <noahm> cool. it'll be good to have the discussion, even if we end up concluding that it doesn't belong in systemd upstream
19:33:20 <chillysurfer> yeah agreed
19:35:15 <rvandegrift> any other topics for today?
19:36:03 <Mrfai> any other MR/issues we want to talk about?
19:36:04 <noahm> Not from me, I think.
19:36:55 <noahm> #action noahm, chillysurfer Follow up on https://github.com/systemd/systemd/issues/11532 about service-specific udev rules in upstream systemd
19:41:02 <noahm> Anything else?
19:41:22 <rvandegrift> I think we're good - thanks everyone
19:41:24 <rvandegrift> #endmeeting