19:00:36 <serpent> #startmeeting
19:00:36 <MeetBot> Meeting started Wed Dec 11 19:00:36 2019 UTC.  The chair is serpent. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:51 <serpent> So - we have few issues
19:01:18 <serpent> First - noahm wrote about still stuck SPI process
19:01:34 <serpent> It looks like waldi is now responsible for it
19:01:40 <serpent> waldi - are you there?
19:02:17 <serpent> Second - zigo mentioned that this time is not the best for him.
19:02:24 <serpent> Any proposals for new time slot?
19:02:41 <Mrfai> I think zigo should propos a better time
19:03:33 * noahm is ~25% here.  I think the spi issue is currently assigned to weasel.
19:03:38 <serpent> From my experiency - it's really hard to came up with time slots that fits 100% of peiple
19:04:51 <Mrfai> Maybe switch/toggle between two time slots, so every may have a chance to join one of the meetings.
19:05:29 <waldi> yeah
19:05:55 <serpent> Mrfai - you mean one month something earlier, more fitting for EU, next month something later (late eveing in EU) more feeting USA?
19:06:04 <serpent> Might be a good idea
19:06:33 <Mrfai> yes, like this
19:07:11 <serpent> #idea Start discussion on mailing list regarding times of IRC meetings, have meetings at various times
19:08:03 <serpent> #action I'll send email to our ML regarding that
19:09:54 <serpent> noahm Sorry. It looks like I misread email, and Martin should take care of it, discussing with waldi
19:10:09 <serpent> #action I'll send emails to both, asking what's the status
19:10:19 <waldi> and zobel is MIA right now
19:10:20 <serpent> waldi - unless you know what's happening now
19:10:35 <serpent> OK, best time I should write him?
19:11:02 <serpent> Is it possible before Christmass, our should I write after New Year?
19:11:22 <waldi> no idea
19:11:40 <noahm> IMO, before and after. ;) we have been blocked for a long time
19:11:49 <serpent> OK, then I'll ping him this week, and if no response I'll repeat in 2020
19:12:00 <serpent> noahm I know
19:13:52 <serpent> #info I wrote Sam (DPL) regarding new delegates, but as he's busy with other teams and GR, he'll take care of it earliest late January/early February
19:14:34 <serpent> So I'll remind him about it at that time
19:15:56 <serpent> And it looks like Arthur is totally redoing his life ( :-) ) so work on image finder is now slower
19:16:31 <Mrfai> IMO this is no problem.
19:16:38 <Mrfai> We still have other things to do.
19:16:48 <serpent> It is deployed and has some data for now.
19:17:22 <serpent> The most important, IMO, is integrating it with our Salsa CI so it receives information about new images (daily)
19:18:05 <serpent> This way, after some time, we can see how it looks like when it has info about few thousands of images in various clouds - how it's usable, how it behaves, etc.
19:18:50 <Mrfai> Will the image finder get the data from petterson or directly from salsa CI?
19:19:44 <serpent> No idea for now - according to our discussion during sprint it should get data from Salsa
19:20:33 <Mrfai> ok. No need in discussing this now
19:24:25 <Mrfai> I would like to discuss issue #14
19:25:07 <Mrfai> waldi: any ideas where this would fit in the json file?
19:27:25 <rvandegrift> maybe adding to data.info makes the most sense
19:27:34 <waldi> Mrfai: no, i haven't thought about it yet. but it needs to go in for both build and upload
19:29:35 <Mrfai> yes data.info makes sense
19:29:36 <waldi> rvandegrift: the data.info dict is a part that needs to be re-structured
19:30:12 <Mrfai> which parts needs to be restructed there?
19:31:17 <waldi> Mrfai: all of it. it is currently defined as an opaque structure, no a well defined piece of data
19:33:24 <rvandegrift> do you think validation/docs would be sufficient waldi?
19:34:23 <waldi> because the job url is no piece of information that's required for any downstream stuff, i think it would be easier to adopt "annotations", which add semi-structured data to objects, without modifying them
19:35:10 <waldi> okay, i have a plan how to handle such information
19:36:42 <Mrfai> it would be nice to open an issue or a MR containing your plan (or an example). Then people may help to implement it.
19:36:59 <waldi> yes
19:37:11 <Mrfai> good
19:38:53 <Mrfai> What about issue #17? I tend to vote for "do not include gpg" in out images.
19:39:09 <serpent> Sounds good. Please create issue or MR and send info to ML
19:39:42 <waldi> no, should not. apt-key needs to die
19:40:08 <waldi> just adding files to /etc/apt/trusted.gpg.d is much easier
19:40:53 <Mrfai> yes, that what I also think
19:41:00 <serpent> IIRC recent discussion (on d-devel or similar) you should not use /etc/apt/trusted.gpg.d/ but create /etc/apt/sources.list.d/*.list with Signed-But
19:41:16 <jcristau> apt-key list is fine. apt-key add not so much.  :)
19:41:27 <waldi> Mrfai: https://salsa.debian.org/cloud-team/debian-cloud-images/issues/14#note_125851
19:41:32 <serpent> Sorry - Signed-By: /usr/share/keyring/deliv-keyring.gpg
19:41:43 <serpent> man sources.list
19:42:26 <noahm> cloud-init uses apt-key, doesn't it?
19:42:27 <serpent> So no need for apt-key etc.
19:42:48 <noahm> So if we want to not use apt-key, we need to fix cloud-init. Otherwise we have broken features there.
19:43:44 <serpent> noahm: probably. I assume https://wiki.debian.org/DebianRepository/UseThirdParty should be consulted here
19:43:54 <Mrfai> do we need to support all parts of cloud-init in our images? Is this an important part of cloud-init we like to support?
19:44:13 <Mrfai> for e.g. GCE images do not use cloud-init IRRC
19:44:20 <Mrfai> IIRC
19:44:36 <waldi> Mrfai: no, we don't need to and we don't do
19:46:51 <Mrfai> Anyone wants to have gpg in our image?
19:47:21 <noahm> gpg is generally useful. And I see no benefit in intentionally breaking this cloud-init feature by refusing to install it.
19:47:26 <noahm> So IMO we should install gpg.
19:47:33 <rvandegrift> ideally no, but I'm worried about breaking users since cloud-init needs it
19:48:10 <serpent> No opinion here, but if it's used by something else, we should install it IMO
19:48:43 <waldi> cloud-init should depend on it, if it needs it
19:48:52 <waldi> or be fixed, which is even easier
19:49:16 <waldi> at the same time it needs to loose this "download key" feature
19:49:37 <noahm> if the key material is provided directly in cloud-config, rather than by key-id, is apt-key still used?
19:50:03 <noahm> If it is, then I think we should install gpg. If it is not, then I don't care. We can suggest that users embed the key directly, which is preferable anyway.
19:51:24 <rvandegrift> from a quick grep, it looks like yes
19:51:33 <Mrfai> yes for what?
19:51:52 <rvandegrift> yes cloud-init uses apt-key to add key material provided directly in the config
19:52:03 <waldi> it uses apt-key add, so it needs to be fixed anyway
19:52:09 <noahm> ok, we should open a bug against cloud-init and get that fixed.
19:52:54 <noahm> then I'm fine with leaving the key download feature "broken" in our images.
19:54:20 <waldi> we need to prepare a cloud-init update for stable
19:54:48 <noahm> yeah, I want to talk about exactly what we update to (see my email to debian-cloud from yesterday)
19:55:19 <noahm> but I can't focus on that discussion here, right now...
19:55:56 <waldi> okay
19:56:27 <Mrfai> I also think we should try to get a newer cloud-init version into stable. A good test to see what needs to be done, and if the release team is willing to support us.
19:56:47 <serpent> noahm: you mean version 19.3 which supports jinja2?
19:56:48 <Mrfai> zigo need to prepare the package?
19:57:31 <waldi> i have some patches pending, but this needs some days
19:57:47 <waldi> then it needs to be in testing. then we can request approval from -release
19:59:30 <serpent> I guess this is good test (-release approval) before all deamons and other cloud-provider-related packages
20:00:09 <waldi> i will prepare the stable update of the azure agent in one or two weeks anyway
20:00:16 <serpent> #idea Update cloud-init (using patches from waldi) and try to put it to stable upgrade
20:00:49 <waldi> #action waldi waagent update in stable
20:01:03 <waldi> #action waldi cloud-init patches for azure
20:02:07 <serpent> Any other topics?
20:02:24 <waldi> noahm: there are no news on the AWS projects?
20:02:56 <noahm> nothing notable.
20:03:13 <waldi> the azure publishing broke the second time on a month. i'm trying to get ms to unstuck it
20:03:41 <noahm> I am hoping to publish (on a limited scale) a buster AMI that contains the kernel from buster-proposed-updates
20:04:07 <noahm> this is to support the Graviton2/Neoverse-N1 arm64 instances that were just launched in AWS.
20:04:23 <noahm> Existing kernels work, but -p-u has better support.
20:05:56 <serpent> You mean that you want to add new /etc/apt/sources.list (.d/* ?) and add kernel?
20:06:01 <serpent> Or something else?
20:06:14 <noahm> just the -p-u sources.list and the kernel from it.
20:07:05 <noahm> it'd be a temporary thing; I have had people ask about images that include this kernel, and I'd like to make something available to them.
20:07:06 <waldi> do you have a plan on how and where?
20:07:20 <serpent> Sounds good, especially if you just create non-official image.
20:07:39 <serpent> Post info about it to ML and wiki so people can test it
20:09:01 <noahm> waldi: would it work to post some changes to branches in the images and daily build repos and run the pipelines on those branches?
20:09:08 <noahm> I think it would, but I could be missing something.
20:09:48 <waldi> noahm: i don't think we should do that. just post them as development images from a branch in your fork
20:09:59 <noahm> yup, that works too
20:12:42 <waldi> anything else?
20:13:40 <serpent> Do we want to have meeing in January?
20:14:09 <Mrfai> yes. Maybe use a different time. And zigo should propose something.
20:14:12 <serpent> As there is New Year and Christmas, I am tempted to have next meeting in early Febryary
20:14:19 <Mrfai> also fine for me
20:14:50 <noahm> I'd be ok with Jan or early Feb.
20:15:37 <serpent> Then let's set up for early February. I'll send initial email to ML, and ask for proposals for alternatives
20:15:46 <noahm> thanks serpent
20:15:52 <serpent> OK.
20:16:04 <serpent> Should we close this meeting then?
20:16:11 <Mrfai> yep
20:17:33 <kuLa> hi all sorry for being so late, but last few weeks are manic
20:18:28 <serpent> kuLa: no problem. We're just closing, next meeting will most probably take place early February 2020
20:18:45 <serpent> I'll open discussion on mailing list about more suiting time slots
20:18:48 <kuLa> ack
20:19:07 <serpent> Thanks everyone for discussion
20:19:14 <Mrfai> bye
20:19:26 <serpent> #action I'll send summary, either during weekend or early next week
20:19:29 <serpent> #endmeeting