19:01:01 <clarkb> #startmeeting infra
19:01:02 <openstack> Meeting started Tue Apr  7 19:01:01 2020 UTC and is due to finish in 60 minutes.  The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:05 <openstack> The meeting name has been set to 'infra'
19:01:12 <clarkb> #link http://lists.opendev.org/pipermail/service-discuss/2020-April/000000.html Our Agenda
19:01:13 <zbr> o/
19:01:20 <clarkb> #topic Announcements
19:01:46 <clarkb> For announcements the big one is the meeting is now here instead of #openstack-meeting. If you are in this cahnnel you already know that, but I had this up as a reminder to notify #openstack-meeting too
19:02:12 <clarkb> we've also got service-discuss@lists.opendev.org up and running. You should join that mailing list if you are interested in working on the services that comprose opendev
19:02:42 <clarkb> if you justwant important announcements service-announce@lists.opendev.org is a good option (and fungi has a change up to udpate that info on https://opendev.org with shiny links)
19:03:29 <fungi> though the site does at least currently mention the new mailing lists
19:03:37 <diablo_rojo> o/
19:03:59 <fungi> so that's a start
19:04:16 <fungi> #link https://review.opendev.org/718188 Add IRC logs and ML subscribe links to opendev.org
19:04:23 <fungi> (for the change clarkb mentioned)
19:04:27 <clarkb> fungi: did infra-manual get updated too?
19:04:42 <fungi> there were no mentions of our ml in infra-manual as far as i could find
19:04:59 <fungi> which i think is likely a glaring omission, but at least did not warrant correcting
19:05:09 <corvus> o/
19:05:27 <fungi> adding it would be a good idea though
19:05:27 <clarkb> fungi: I think there may be one or two occurences. I'll try to take a look after the meeting
19:05:42 <fungi> possible my git grep was wrong
19:06:03 <mordred> o/
19:06:12 <corvus> so mordred will handle all of that then.. great!
19:06:21 <clarkb> works for me
19:06:25 <fungi> clarkb: i take that back, it turns up the setup.cfg
19:06:38 <fungi> which i noticed but figured was not worth correcting on its own
19:07:01 <clarkb> fungi: doc/source/index.rst and doc/source/creators.rst too looks like
19:07:07 <clarkb> #topic Priority Efforts
19:07:15 <clarkb> Lets dive right into the bulk of the meeting
19:07:23 <clarkb> #topic Update Config Management
19:07:43 <clarkb> mordred: you've been pushing most of this along the last little while. Would you like to summarize some of the updates to how we are config managementing now
19:07:58 <fungi> clarkb: oh! i searched for the e-mail address, yep, we have the hyperlink in there, will fix
19:08:37 <mordred> yes! so - there's this great stack everyone should review
19:08:50 <mordred> https://review.opendev.org/#/q/topic:infra-prod-zuul+status:open
19:09:12 <mordred> but we've made great progress on shifting things from running out of cron on bridge.openstack.org to being triggered by zuul
19:09:21 <mordred> for many things things means we can insta-run them on landing
19:09:48 <mordred> there are a few things where we have external deps (and in this case external also includes zuul) - where we still need to also run periodically
19:09:54 <mordred> so we added a new hourly pipeline to run those in
19:10:16 <mordred> the whole stack should be ready to go - it's just about landing things as we're comfortable
19:10:24 <mordred> as a note - logs are not being collected and published by default
19:10:42 <mordred> there is a flag for that and we should only set it on a per-job basis once we've verified that the logs don't contain secret infos
19:11:18 <mordred> I've also got a dockerized etherpad in progress, and a patch up for dockerized zuul
19:11:33 <clarkb> https://review.opendev.org/#/c/718161/ is a change I wrote to make that verification of logs easier (as well as finding historical lgso in the current setup)
19:11:42 <clarkb> basically it will curate the logs on bridge for you
19:12:07 <mordred> yah. end-goal should be that we don't have logs only on bridge- but it might take us a little bit to safely get tehre
19:12:25 <corvus> oh nice
19:13:23 <clarkb> one thing that I thought about yseterday when debugging gerrit weirdness is we are still not running containered gerrit yet are we?
19:13:25 <mordred> https://review.opendev.org/#/c/717620/ is the zuul patch fwiw - there is a blocker with that we'll need to figure out, which is using AFS from bubblewrap from inside docker
19:13:30 <clarkb> should we plan to make that restart happen soon?
19:13:33 <mordred> clarkb: no - we need to do a restart
19:13:35 <mordred> and yse
19:13:46 <mordred> basically just need a stop/start cycle
19:13:53 <mordred> so it shouldn't be a long downtime
19:14:01 <clarkb> maybe friday g=considering it is a holiday in many parts of the world?
19:14:07 <mordred> ++
19:14:08 <clarkb> not sure where the g= came from
19:14:22 <mordred> google probably added it for you
19:14:46 <fungi> g++
19:15:05 <fungi> (maybe gnu added it for you!)
19:15:51 <clarkb> alright anything else related to config management?
19:16:35 <mordred> I think that's it from me
19:17:07 <clarkb> #topic OpenDev
19:18:00 <clarkb> Now that we've started getting the forward looking comms channels stuff set up I/we (though I'm volunteering, help apprecaited if interested) need to start the ball rolling on project leadership formalization as well as building the advisory board
19:18:22 <clarkb> Today is supposed to be nice and sunny so I'll work on drafting some emails to the list to kick that off (I'll share them in etherpads)
19:18:35 <fungi> #link https://review.opendev.org/718193 Update contact info for OpenDev community
19:18:37 <clarkb> my picnic table should be well positioned for writing emails :)
19:18:53 <fungi> just to follow up on my terrible git grep skills earlier
19:19:04 <fungi> (infra-manual edits)
19:19:22 <clarkb> yup the other half of this is updating links and documents as necessary. If you find some old info please send up a patch or let someone know and we'll get a patch up
19:20:36 <clarkb> and more generally if you find documents that are out of date or could use a perspective shift let us know (doesn't have to be limited to the new comms channels)
19:20:53 <clarkb> the Get Started links on gitea are a good example of that turning out to be a positive chagne for everyone :)
19:21:45 <clarkb> fungi: did you want to talk about the authentication stuff now?
19:21:55 <fungi> oh, yeah probably good to revisit that
19:22:19 <fungi> mainly just thinking we're reaching the point where it warrants rekindling the sso efforts we've started multiple times in the past
19:22:28 <mordred> ++
19:22:42 <fungi> revisiting some old ground, also seeing what might be new since the last time we looked
19:23:00 <fungi> i was going to hit knikolla up for a bit more detail on the thing morgan had started working on for keystone
19:23:33 <fungi> also i think i'm going to write a spec
19:23:50 <fungi> even though it may be premature with no actual software identified we can use
19:24:15 <fungi> we basically have no documentation i've been able to find anywhere of the discussions we've had previously about what it is we want out of an sso implementation
19:24:18 <clarkb> fungi: if it can identify specific use cases as well as what we need to transition from that would probably be helpful even without specific suggestions
19:24:19 <mordred> it's worth noting that since last we looked the governance of dex has changed - and we also run things in containers now (which I believe was one of our concerns with it before, it was sort of "run me in containers" centric)
19:25:02 <clarkb> mordred: there is also a newish thing called gluu that I ran across
19:25:07 <fungi> well, also some brief re-researching suggests we may want to consider options like completely dropping launchpad authentication
19:25:12 <mordred> I believe we'd have to implement an openid v1 provider for dex if we wanted to use it and continuing having launchpad be a login source - but it _is_ an SSO proxy project, so other than lack of openid v1 it does seem to understand our use case
19:25:26 <mordred> cool
19:25:39 * mordred is guessing we;ll have to add openidv1 support to _anything_ we wind
19:25:41 <mordred> find
19:25:54 <clarkb> mordred: or give up on openidv1 entirely
19:26:00 <fungi> it seems launchpad never moved beyond very early openid protocols, and none of the currently maintained identity solutions out there support the protocols it uses these days
19:26:46 <clarkb> launchpad implements some subsets of other things like saml and oauth but only for their internal usage apparently? I have no idea if that might provide us a stepping stone or not
19:26:56 <clarkb> but definitely interested to start writing all this down
19:27:01 <fungi> so yes, we should weigh whether a coordinated forklift of users with no clean migration from launchpad is more or less work than writing openid v1 support into whatever we end up deciding on
19:27:18 <mordred> agree
19:27:41 <fungi> that was the biggest sticking point i recall morgan running up against in his last attempt
19:28:06 <mordred> yeah - our existing login data being openid v1 from launchpad is challenging :)
19:28:07 <fungi> so keeping in mind that may simply be an unsatisfyable requirement and considering alternative options
19:28:11 <mordred> yup
19:28:40 <mordred> I don't think we need to keep launchpad as an ongoing auth source - but I do think we should be able to migrate and have people still able to log in to their gerrit account
19:29:02 <fungi> anyway, that's all i had, mostly just wanted to be sure folks think it's reasonable to whip up a spec to try and express what we want, even if we don't have more than a loose design plan so far
19:29:05 <mordred> ++
19:29:07 <mordred> yes please
19:29:23 <mordred> clarkb: gluu also doesn't support openidv1
19:29:28 <clarkb> mordred: ya basically nothing does
19:29:48 <clarkb> once google killed it everyone seemed to stop supporting it
19:30:18 <corvus> it's pretty easy to add to anything written in python
19:30:22 <fungi> i've also heard rumors that some red hat employees don't want to interact with opendev services because it requires them to sign in with an ubuntu account, so providing more neutrally-branded options will hopefully satisfy some of those seemingly irrational objections
19:30:37 <mordred> clarkb: fwiw - dex does jwt (good for zuul) and gluu does UMA - so that's a thing we should consider too
19:31:12 <mordred> fungi: for the record, I am not motivated by sectarianism, and might be anti-motivated by that
19:31:14 <mordred> BUT
19:31:22 <mordred> I still think we need a better SSO story
19:31:32 <fungi> yes, which is my primary motivation
19:31:42 <corvus> at the very least, if there's a spec (or even a draft spec), you can just point them at that and say 'patches welcome'
19:31:44 <fungi> well, that and not being wholly dependent on a single identity provider we don't control
19:31:51 <mordred> yup
19:31:52 <fungi> corvus: yep, precisely
19:31:55 <clarkb> mordred: I believe UMA is a superset of jwt so it may all just work
19:31:59 <mordred> clarkb: cool
19:32:06 <clarkb> (if it comes down to a uma providing tool being preferable)
19:32:27 <mordred> oh - other differences - gluu is java, dex is go - neither is python
19:32:39 <fungi> corvus: in fact i wanted to pass along the "patches welcome" invitation along with a link to our plan, and then realized i couldn't find it written down anywhere
19:33:06 <clarkb> but ya I'm not super concerned about specific tools as much as "the tools in the space ahs changed lets reevaluate with some concrete use cases/requirements/goals"
19:33:14 <mordred> clarkb: ++
19:33:15 <corvus> i think there was a (draft) spec, i'm not sure we ever approved it?
19:33:35 <fungi> corvus: maybe it got abandoned, i checked proposed specs and didn't see one
19:33:44 <fungi> also possible i'm blind
19:34:08 <fungi> if the old spec can be found i'm happy to resurrect/revise/whatever
19:34:16 <fungi> will go back and look again to be certain
19:35:00 <clarkb> thanks!
19:35:30 <corvus> it looks like ubuntu one uses oauth for the desktop portion of things
19:35:49 <corvus> i wonder if there might be something usable there?
19:35:53 <fungi> that sounds like it would have to be public-facing then
19:35:57 <clarkb> corvus: ya there is definitely some stuff to investigate there as option for migration
19:36:24 <clarkb> fungi: I believe its all public facing, but they don't do fully spec compliant implementations, they just do the subset they need for $usecase
19:36:26 <corvus> (or continued support for people who want to keep using that)
19:36:40 <clarkb> so if our use case can fit into that subset (and we can figure out how to integrate with launchpad with no docs) that may be viable
19:36:42 <mordred> maybe it's enough for a transition
19:36:43 <mordred> yeah
19:37:42 <fungi> also i just went back over open and abandoned specs and didn't find it. i thought i remembered an outline in a mailing list post (maybe from corvus) several years back, but my searching was insufficient to locate it
19:37:54 <fungi> might be remembering the old idp poc
19:37:54 <corvus> i thought mordred wrote it
19:37:59 <fungi> ahh, perhaps
19:38:00 <mordred> I think I might have sent the email
19:38:03 <mordred> but I also can't find it
19:38:05 <mordred> I remember writing it
19:38:19 <fungi> well, at this point it's likely easier to just redo from scratch
19:38:21 <fungi> enough has changed
19:38:32 <fungi> i'll see what i come up with
19:38:38 <mordred> yeah - I think the biggest benefit of finding it might have been the part where we describe the use case
19:39:14 <fungi> anyway, didn't want to suck up this much of the meeting
19:39:43 <clarkb> there wasn't much else on the agenda. Why don't we finish that up then can continue this discussion after if we have time
19:39:57 <clarkb> Does anyone else have OpenDev related items to bring up (that was all I had)?
19:41:27 <clarkb> #topic General Topics
19:41:36 <clarkb> Only one entry here, the wiki entry.
19:41:50 <clarkb> fungi: fwiw I am happy to remove it, but since we've been good at ignoring the wiki in the past I don't want to forget it if there is movement on it
19:42:09 <clarkb> I don't think there has been recent movement. Let me know if you think its useful to have the check ins or if we should remove this from the agenda
19:42:56 <fungi> there has not, i also am not sure it's useful to revisit weekly, but am unopposed
19:43:12 <fungi> maybe i or someone will take it as a cue to do something
19:43:55 <clarkb> k
19:44:00 <clarkb> #topic Open Discussion
19:44:16 <clarkb> feel free to discuss the authentication stuff more now. Or bring up other items
19:44:53 <fungi> i didn't really have anything else on that topic for now, but if folks had more suggestions i'm game
19:45:46 <ianw> i'm making some progress on removing pip-and-virtualenv
19:46:21 <ianw> basically going through zuul-jobs and figuring out where we've made assumptions that pip and virtualenv exist on the platform they're running on
19:47:36 <ianw> this has come to more of a head with latest fedora's and suse's dropping python2 support, making changes required in the pip-and-virtualenv element that would make it even crazier than it already is
19:47:37 <mordred> it's maybe worth mentioning there is a big pile of changes in zuul-jobs  that just landed to rename things from install- to ensure-
19:48:02 <mordred> ianw: ++
19:48:14 <fungi> good timing in that case!
19:48:22 <ianw> yep, ensure-* seems to fit what we do much better
19:50:51 <fungi> i feel like moving the meeting to our shiny new channel has also made it faster
19:51:06 <clarkb> fungi: there was also lots of fire fighting over the last week
19:51:09 <clarkb> or maybe it seemed that way
19:51:16 <fungi> no, there definitely was
19:51:41 <fungi> the past several weeks really
19:52:23 <clarkb> sounds like that may be it for the meeting?
19:52:31 <clarkb> I'll go ahead and call it a few minutes early.
19:52:33 <clarkb> THanks everyone!
19:52:35 <fungi> our first early finish in... ages
19:52:36 <clarkb> #endmeeting