16:00:01 <lbragstad> #startmeeting keystone
16:00:02 <openstack> Meeting started Tue Jan 29 16:00:01 2019 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'keystone'
16:00:08 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:11 <lbragstad> agenda ^
16:00:16 <lbragstad> o/
16:00:44 <knikolla> o/
16:00:48 <wxy|> o/
16:00:49 <cmurphy> o/ dual meetings again
16:00:54 * kmalloc drinks coffee.
16:01:33 * knikolla finished coffee already but doesn't want to be hypercaffeinated.
16:01:40 <lbragstad> looks like we have some good topics on the agenda - so let's get started
16:01:48 <lbragstad> #topic previous action items
16:01:58 <vishakha> o/
16:02:09 <lbragstad> last week we recapped the notes cmurphy put together for keystone's version of the technical vision statement from the TC and how we fit into that
16:02:26 <lbragstad> #link https://etherpad.openstack.org/p/keystone-technical-vision-notes
16:02:52 <lbragstad> i'm curious if anyone wants to take a stab at proposing whats in the etherpad for review to our contributor guide
16:03:17 <lbragstad> we can massage the wording and iterate using gerrit
16:03:28 <kmalloc> where do you see this documentation going?
16:03:34 <kmalloc> within our doc tree that is
16:03:42 <lbragstad> https://docs.openstack.org/keystone/latest/contributor/index.html
16:03:53 <kmalloc> straight on the index page then.
16:04:06 <lbragstad> imo - it fits well with the contributor guide
16:04:08 <kmalloc> [link that is]
16:04:09 <kmalloc> ok
16:04:19 <lbragstad> but if folks have other suggestions as to where this should live, i'm curious to hear them
16:04:31 <kmalloc> i wasn't sure if there was a standard place or if it was per-project
16:04:45 <kmalloc> i was kindof hoping the TC had a direct/standard recommended.
16:05:00 <kmalloc> so fokls don't have to guess whereabouts for each service
16:05:11 <kmalloc> contributor guide makes sense.
16:05:31 <lbragstad> the unofficial recommendation was to put it into the contributor guide
16:05:36 <lbragstad> of each project
16:05:55 <lbragstad> if there was additional detail or differences the projects had in vision with what the TC had outlined
16:06:08 <kmalloc> so, i do want to point out that the data in that etherpad is extremely rough. it probably has to be someone familiar/worked with keystone for a time to convert it into coherant words.
16:06:45 <cmurphy> they are mostly my notes so I can put this on my backlog
16:07:31 <kmalloc> even as a core, i am hesitant to volunteer to turn that into something polished -- it is very rough. if it can be made slightly less stream of consciousness i'd be happy to convert it to usable/polished words.
16:07:48 <lbragstad> sounds good
16:08:05 <cmurphy> yeah sorry this just started out as my random notes as i was reading
16:08:36 <kmalloc> no problem. I'm happy to help, it's very much as you said some random notes atm.
16:08:42 <lbragstad> which i threw into the spot light immediately ;)
16:08:54 <ayoung> cmurphy, post if for review on Gerrit and you know we'll all have lines to modify/contrib
16:09:05 <cmurphy> ayoung: will do
16:09:08 * kmalloc votes lbragstad takes a pass at it... you know... being the person who put a spotlight on it :P
16:09:23 <lbragstad> yeah - that's fair
16:09:27 <kmalloc> cmurphy: ^ trying to toss lbragstad under the doc bus for you :P
16:09:32 <cmurphy> lol
16:09:53 <lbragstad> fwiw - if we put this in review i can tag-team it
16:10:07 <cmurphy> ++
16:10:10 <kmalloc> yeah. and i can def. help as well.
16:10:14 <cmurphy> is there a timeline on this?
16:10:14 <lbragstad> cool
16:10:24 <kmalloc> cmurphy: sometime before the U release (/s)
16:10:32 <lbragstad> not really - but this is the furthest we come to ever having a technical vision statement for the project
16:10:46 <lbragstad> i just don't want it to get lost in the shuffle
16:10:48 <kmalloc> i'm guessing we should aim for sometime around when stein cuts RC.
16:10:53 <kmalloc> at the latest
16:10:56 <cmurphy> I'll aim for having something rough up a few weeks before ptg
16:11:08 <lbragstad> i like that idea
16:11:09 <kmalloc> it will inform some choices for train and beyond.
16:11:36 <lbragstad> i can see this being useful at the forum/ptg
16:12:24 <lbragstad> sounds like we have a plan
16:12:25 <lbragstad> moving on
16:12:27 <lbragstad> thanks cmurphy
16:12:37 <lbragstad> #topic Alembic instead of sqlalchemy-migrate
16:12:41 <lbragstad> vishakha o/
16:13:09 <vishakha> I wanted to grab the attention of keystone team towards these migratons
16:13:55 <vishakha> Since the maintainer of sql aclchemy is deprecating this and wanted to move towards alembic
16:13:58 <kmalloc> the only reason we have not made the move is bandwidth.
16:14:06 <kmalloc> it's been on our wishlist for a while.
16:14:20 <kmalloc> I support and will review anyone's code to make the conversion.
16:14:33 <cmurphy> could someone tldr the reason to migrate for me?
16:14:52 <kmalloc> cmurphy: sql-alchemy-migrate is effectively a dead project
16:15:00 <kmalloc> it's been on life-support for a while.
16:15:07 <vishakha> Yea even glance took two cycles to migrate
16:15:07 <cmurphy> got it thanks
16:15:26 <vishakha> There were two people involved in this
16:16:05 <kmalloc> mike bayer (zzzeek) maintains alembic directly for SQL-A as a first-party support. -- it's also generally better, but it takes some work to get moved over to it, and a slightly different workflow to make migrations.
16:16:20 <kmalloc> :)
16:16:34 <cmurphy> might be a good idea to revive our rolling upgrades testing before starting on a refactor
16:16:49 <lbragstad> ++
16:16:50 <kmalloc> as i recall, alembic should be mostly drop in.
16:17:00 <lbragstad> we need to revisit all that stuff anyway
16:17:13 <lbragstad> that stuff == how we approach upgrades and migrations
16:17:26 <kmalloc> s/drop in/fully capable of running the old migrations with some added tooling.
16:18:07 <kmalloc> we need to re-work the rolling upgrades and very clearly line out the expected order and at least test that order [even if it ins't multi-node]
16:18:15 <ayoung> So....we would need to make a cut, and say all migrations from point X on forward are Alembic
16:18:29 <ayoung> we've discussed it before.
16:18:36 <kmalloc> ayoung: that would be the plan, and that would come with a conversion to alembic in our tooling
16:18:50 <kmalloc> the tooling cutover would be the point in which migrations would cut over
16:18:51 <ayoung> Could we do a release where we say "only additive changes to SQL?"
16:19:01 <kmalloc> we already did that
16:19:05 <ayoung> like, no columns dropped etc
16:19:09 <kmalloc> like.... ages ago
16:19:13 <ayoung> a release, not a phase
16:19:20 <kmalloc> it's the expand/migrate/contract bits
16:19:24 <ayoung> we are going to do expand contract
16:19:30 <kmalloc> i'd say no not a release.
16:19:40 <kmalloc> there are reasons to have a contract phase.
16:20:05 <kmalloc> so not explicitly "only expand/migrate" release. but it might be there are no logical contracts for the release
16:20:16 <ayoung> so  what if we did:
16:20:30 <ayoung> for each p[hase, first sqla, then alembic
16:20:33 <ayoung> nah...
16:20:56 <ayoung> I'm trying to think how not to logjam people on the cut over of mechanis
16:20:57 <ayoung> m
16:21:14 <kmalloc> db_sync will handle the change for users/deployers/operators
16:21:18 <kmalloc> just like today
16:21:30 <kmalloc> developers will need to make alembic migrations (minorly different)
16:21:37 <ayoung> ok...what if....
16:22:11 <ayoung> lets ssume we started in the middle of a release.  A bunch of SQL A migrations are already approved
16:22:15 <kmalloc> really, the hardest part of alembic is knowing that by default the schema is not numbered, it has a uuid.
16:22:28 <ayoung> but there is an ordering, right?
16:22:31 <kmalloc> yes.
16:22:36 <ayoung> its just like git, a hash of the previous...
16:22:44 <kmalloc> sortof?
16:22:49 <ayoung> so...we think of it like a stack
16:23:07 <ayoung> we state that for all migrations, they are SQL A first, then Alembic
16:23:26 <kmalloc> you're overthinking it :P
16:23:43 <kmalloc> db_sync will be tooled to run them both.
16:23:44 <ayoung> Do we just cut over at a release boundary?
16:23:52 <ayoung> Oh, I ghet that
16:23:52 <kmalloc> and we just cut over when the code is ready
16:24:01 <kmalloc> it should not be a ton of code.
16:24:01 <ayoung> but what about migrations in flight?
16:24:10 <kmalloc> if they are approved they land
16:24:15 <ayoung> do we let people submit them in both?
16:24:16 <kmalloc> if they are not, they get rebased.
16:24:24 <kmalloc> and need to get minor reworking...
16:24:35 <kmalloc> we have almost no (any?) migrations in flight right now.
16:24:58 <kmalloc> standard land-code-gate-process.
16:25:09 <kmalloc> we could wait until feature-freeze to land alembic swap over
16:25:46 <kmalloc> but really, it should be minimally invasive and no different than the other race-to-rebase that happens in the gate.
16:26:02 <kmalloc> vishakha: tl;dr - we should move to alembic :)
16:26:10 <ayoung> I like the idea of doing it at feature freeze
16:26:21 <vishakha> yeah :)
16:26:27 <kmalloc> we can discuss timing outside of the meeting.
16:26:33 <lbragstad> we could also try and get it done first thing in the cycle, too
16:26:40 <vishakha> sure. Thanks.
16:26:42 <kmalloc> lbragstad: i'd rather do it at the end of a cycle
16:26:43 <ayoung> lbragstad, that is why at feature freeze
16:26:56 <kmalloc> in case it bleeds over, then it can land first in T.
16:26:58 <ayoung> its prepped and ready to go with all the previous changes
16:27:01 <kmalloc> just hedging bets.
16:27:11 <lbragstad> sounds like we still need to work out some technical details
16:27:24 <kmalloc> for this one, i think code talks.
16:27:30 <ayoung> yep.  But I'm in favor of the cut over
16:27:36 <kmalloc> we should get a review up for the cut over
16:27:43 <kmalloc> it might just work(tm)
16:28:12 <lbragstad> ok - i guess we'll discuss technical details in the channel
16:28:30 <lbragstad> if that's cool with everyone? but it sounds like we have consensus on the need to move to alembic
16:28:39 <lbragstad> does anyone object?
16:28:42 <cmurphy> thanks for bringing it up vishakha
16:29:09 <knikolla> ++
16:29:19 <vishakha> sure we can discuss on channel
16:29:33 <lbragstad> thanks vishakha
16:29:44 <lbragstad> #topic Next outreachy round
16:29:46 <lbragstad> cmurphy o/
16:29:59 <cmurphy> this is just a short announcement
16:30:19 <cmurphy> the outreachy people notified me that the project submissions are open for the next round
16:30:25 <cmurphy> #link https://www.outreachy.org/communities/cfp/openstack/
16:30:46 <cmurphy> they recommend submitting sooner rather than later because interns are going to start applying soon
16:31:01 <lbragstad> soon as in days? or weeks?
16:31:48 <cmurphy> february i think
16:32:10 <lbragstad> do we have anything we know we want to submit?
16:32:12 <cmurphy> I don't plan on submitting a project myself or being a lead mentor but I can answer questions about the process if anyone is interested and I can be a comentor
16:33:24 <lbragstad> ack
16:33:34 <cmurphy> I don't have any projects in mind personally, but wanted to raise it so that people can brainstorm
16:33:42 <lbragstad> sounds good
16:33:46 <lbragstad> thanks cmurphy
16:33:48 <cmurphy> np
16:34:02 <lbragstad> #topic x509 shtuff
16:34:14 <lbragstad> so - this was a fun puzzle
16:34:39 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002085.html
16:34:52 <lbragstad> i attempted to summarize stuff in that post ^
16:35:23 <lbragstad> i'm curious if folks have thoughts, or see themselves helping out with the refactor
16:35:31 <lbragstad> sounds like penick has some resources that can help
16:35:42 <cmurphy> gyee is in a meeting right now but I think he was interested in digging in
16:36:06 <lbragstad> ++ that'd be good, because i'm certain he has context as the author that the rest of us don't
16:37:01 <cmurphy> I'll try to look into it too
16:37:05 <lbragstad> all in all - i think if we got this working as designed, there are a lot of things we could do with it that would be really cool
16:37:38 <lbragstad> it would be easier to test federation in the gate for example
16:37:42 <lbragstad> which would be a huge win
16:37:45 <vishakha> I will also look for it
16:38:06 <lbragstad> we would also have a path forward for fixing the bearer token problem we have in openstack
16:38:14 <lbragstad> which would be pretty neat
16:39:51 <lbragstad> does anyone have questions about that summary or the bugs we opened for x509/tokenless authentication last week?
16:42:23 <lbragstad> well if you do or something comes up, don't hesitate to ask
16:42:28 <lbragstad> that's all i ha
16:42:30 <lbragstad> had*
16:42:33 <lbragstad> #topic open discussion
16:42:37 <lbragstad> floor is open
16:42:50 <lbragstad> does anyone have comments, questions, or concerns they'd like to raise?
16:42:57 * kmalloc dances on the open floor.
16:43:41 <lbragstad> fwiw - i did go through a bunch of bug backlog yesterday
16:43:59 <lbragstad> and i attempted to match up when bugs were fixed to the milestone they were fixed in
16:44:05 <lbragstad> for context
16:44:34 <lbragstad> we fixed 70 bugs in pike, 38 bugs in queens, 60 bugs in rocky, and we've fixed 36 so far in stein
16:44:48 <lbragstad> (not that numbers are a great indicator)
16:45:25 <cmurphy> I ran into a slight stumbling block in the app creds whitelist implementation, the spec says that ksm will check the service id but afaict ksm actually doesn't know its own identity, it can't know the service ID or even the service type of the service it's running in
16:45:52 <cmurphy> for now i have a new parameter in [keystone_authtoken] that gives the service type
16:45:52 <kmalloc> yeah that is a gap we've needed to fix for a LONG time.
16:46:19 <kmalloc> yep, config value, possibly something that can be set by the service with a config_default thing.
16:46:30 <cmurphy> mmk
16:47:00 <kmalloc> i also recommend not using ID
16:47:10 <kmalloc> use a human readable string, if we need to fix the spec we can
16:47:17 <kmalloc> uuids in config suck :P
16:47:46 <cmurphy> yeah my wip patch has the human readable service type
16:47:50 <kmalloc> ++
16:47:53 <kmalloc> perfect :)
16:48:08 <cmurphy> we could integrate os_service_types to let it use either service name or service type but eh
16:49:10 <kmalloc> future looking stuff
16:49:16 <kmalloc> start easy, expand.
16:49:23 <cmurphy> ++
16:50:00 <lbragstad> oh - i forgot to ask earlier
16:50:06 <lbragstad> does anyone have reviews that need eyes?
16:52:49 <lbragstad> i appreciate people taking a look at - https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles
16:53:06 <lbragstad> still a few patches up there if folks are looking for reviews
16:53:11 <cmurphy> oh another announcement, one of our interns got their first patches merged and now the keystone devstack plugin supports centos :D
16:53:22 <knikolla> \o/
16:53:30 <lbragstad> nice!
16:55:25 <lbragstad> alright - if there isn't anything else, looks like we can get a few minutes back
16:55:30 <lbragstad> office hours is starting shortly
16:55:57 <lbragstad> i appreciate y'all taking the time to be here
16:56:02 <lbragstad> #endmeeting