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