18:01:56 <lbragstad> #startmeeting keystone
18:01:56 <openstack> Meeting started Tue Mar  7 18:01:56 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:00 <openstack> The meeting name has been set to 'keystone'
18:02:03 <lbragstad> ping agrebennikov, amakarov, annakoppad, antwash, ayoung, bknudson, breton, browne, chrisplo, cmurphy, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nishaYadav, nkinder, notmorgan, portdirect raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, SamYaple, shaleh, spilla, srwilkers,
18:02:03 <lbragstad> StefanPaetowJisc, stevemar, topol, shardy, ricolin
18:02:04 <knikolla> o/
18:02:06 <gagehugo> o/
18:02:07 <rderose> o/
18:02:08 <lbragstad> agenda #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:02:11 <lbragstad> o/
18:02:12 <cmurphy> o/
18:02:16 <lamt> o/
18:02:22 <unrahul> o/
18:02:23 <dstanek> ehlo
18:02:26 <knangia> o/
18:02:50 <lbragstad> we have a lot on the agenda today - so i'll get started wth announcements as folks trickle in
18:02:56 <lbragstad> #topic Announcement: Pike deadlines
18:03:02 <lbragstad> #link https://review.openstack.org/#/c/441999
18:03:29 <lbragstad> I proposed our deadlines for Pike and I'm going to double check those today
18:03:41 <lbragstad> and resolve the merge conflict
18:03:54 <lbragstad> but I'd expect to have those cleaned up and merged sometime this week
18:04:07 <spilla> o/
18:04:20 <lbragstad> just giving everyone a heads up so that they know what we have for a schedule in Pike as far as deadlines go
18:04:30 <lbragstad> #topic Announcement: New release of keystoneauth today after the following merge
18:04:37 <lbragstad> #link https://review.openstack.org/#/c/442516/
18:04:37 <lbragstad> #link https://review.openstack.org/#/c/442536/
18:04:43 <lbragstad> just for awareness
18:04:55 <lbragstad> if there is anything folks want in the next release of ksa - let me know
18:05:09 <lbragstad> otherwise we'll be cutting the first version for pike sometime today or tomorrow
18:05:29 <lbragstad> alright - on to the fun stuff
18:05:29 <lbragstad> #topic VMT follow up from PTG
18:05:31 <lbragstad> Followed up with a few folks from OpenStack Security that have some good information we can use to forward with VMT for identity related projects
18:05:38 <notmorgan> those are test fixture changes btw ^ the ksa bits
18:05:39 <lbragstad> ping michaelxin, knangia, xin9972, unrahul
18:05:52 <lbragstad> knangia unrahul o/
18:06:01 <lbragstad> #link https://openstack-security.github.io/collaboration/2016/04/26/threat-analysis-process.html
18:06:01 <lbragstad> #link https://openstack-security.github.io/collaboration/2016/01/16/threat-analysis.html
18:06:03 <unrahul> hey lbragstad
18:06:19 <knangia> hey lbragstad
18:06:21 <unrahul> so  michealxin won't be available today
18:06:31 <lbragstad> unrahul knangia thanks for dropping by!
18:06:44 <unrahul> sure lbragstad , let us know how we may help out
18:06:58 <lbragstad> unrahul knangia would you mind giving us a brief introduction to what you both do?
18:07:40 <unrahul> yup so we are both from OSIC security team, mainly working on the openstack security testing project syntribos
18:07:54 <unrahul> we are members of the openstack security project
18:08:04 <lbragstad> nice
18:08:20 <lbragstad> unrahul it sounds like you are both familiar with the VMT security analysis process as well?
18:09:17 <unrahul> We have participated in the initial discussions on security analysis of barbican, it was mostly driven by Rob clark and Doug chivers from the security team
18:09:41 <lbragstad> awesome - we poked around at that document during the PTG
18:09:43 <unrahul> And if you guys are initiating a security analysis for keystone, I would recommend involving either of them
18:09:46 <lbragstad> and used it as a reference
18:09:53 <unrahul> great..
18:10:02 <lbragstad> unrahul do they have irc nicks?
18:10:08 <knangia> exactly, participated in barbican threat analysis, but mostly i guess, michael xin can guide us
18:10:09 <notmorgan> yes, the goal is to get Keystoneauth, KeystoneMiddleware, and Keystone reviewed
18:10:47 <lbragstad> yeah - we were planning on starting with keystonemiddleware (at least according to our etherpad) #link https://etherpad.openstack.org/p/pike-ptg-keystone-vmt-coverage
18:10:57 <unrahul> yes, hyakuhei and capnoday
18:11:00 <notmorgan> the VMT only covers keystone server at the omment and an updated analysis is definitely in order sinc e keystone has changed a TON since it split from Nova
18:11:22 <notmorgan> as has ksm.
18:11:29 <lbragstad> right
18:11:43 <unrahul> so keystone middleware is the one that you are going to start with?
18:11:56 <lbragstad> unrahul i think that was the initial plan
18:12:01 <lbragstad> right notmorgan?
18:12:21 <notmorgan> whatever was agreed to is what we are doing. :P
18:12:27 <notmorgan> i am going to say sure ;)
18:12:46 <gagehugo> yeah the three listed in the etherpad were the first goals I believe from the PTG
18:12:49 * notmorgan can only do so much being split in all the ways I am, so, defering to the notes taken from the meetings
18:13:02 <lbragstad> i believe that was the action item
18:13:12 <knangia> ok
18:13:28 <lbragstad> the goal was to see if we could get ksm done first
18:13:30 <lbragstad> and since it is a smaller code base, i think that would be a good start?
18:13:38 <notmorgan> i'm just glad folks are taking interest in this and helping to make those of us working on the VMT lives easier.
18:13:46 <lbragstad> ++
18:13:57 <unrahul> In any case, we need to have a well defined architectural diagram to identify background information and data flow paths, trust boundaries etc.
18:14:03 <lbragstad> i was super relieved to hear that unrahul and knangia were working on this, too
18:14:24 <lbragstad> unrahul so it coming up with that diagram the first step?
18:14:29 <unrahul> So we need to have a latest architectural diagram first
18:14:31 <unrahul> yes lbragstad
18:14:36 <lbragstad> unrahul cool
18:14:41 <knangia> yes, the architecture diagram should be the start
18:15:07 <lbragstad> ok - so that'd be something we as the keystone team would be on the hook for
18:15:20 <knikolla> we might also improve our developer docs in the process of this
18:15:29 <lbragstad> then i assume we work on it together?
18:15:41 <lbragstad> knikolla ++ i was just thinking about that super old keystonemiddleware arch document we have
18:16:00 <unrahul> And we are not actively working on the threat analysis, but yes have participated in the initial draft of barbican during our mid-cycle. We are willing to help in anyway we can, especially with michaelxin having extensive experience in the field.
18:16:39 <knangia> https://openstack-security.github.io/collaboration/2016/04/26/threat-analysis-process.html
18:16:43 <lbragstad> unrahul ok - do you need the diagram in any particular format?
18:16:48 <knangia> for reference ^^
18:17:14 <unrahul> Here is a sample diagram of barbican https://github.com/openstack/security-analysis/blob/master/doc/source/artifacts/barbican/newton/architecture-page.rst
18:17:50 <lbragstad> aha
18:17:51 <unrahul> it was mostly done on draw.io
18:18:00 <gagehugo> interesting
18:18:04 <notmorgan> ah i was wondering what tool was used
18:18:14 <unrahul> notmorgan:  draw.io
18:18:18 * notmorgan has been using ascii-flow, but draw.io is way way cooler
18:18:36 <knangia> cool tool
18:19:03 <unrahul> A diagram such as this would enable us to identify data assets, its impact and how the system talks with the outside world
18:19:15 <unrahul> notmorgan:  ascii-flow is indeed cool :)
18:20:12 <knangia> yes, so should know the assets, its impacts, trust boundaries with th help of diagram
18:20:16 <lbragstad> is anyone from the keystone team interested in taking a stab at updating our ksm architecture doc and doing the diagram?
18:20:43 <lbragstad> fwiw - this would only be fore ksm initially
18:20:46 <gagehugo> I'd be willing to help
18:21:04 <lbragstad> gagehugo awesome - anyone else feel like tag-teaming it?
18:21:11 <knikolla> o/
18:21:11 <gagehugo> I'm not a great artist though :(
18:21:29 <lbragstad> gagehugo that's what draw.io is for ;)
18:21:30 <lbragstad> knikolla yeah?
18:21:40 <lbragstad> knikolla gagehugo i'll put you both down for it then?
18:21:49 <gagehugo> sounds good
18:21:54 <knikolla> sounds good
18:21:58 <lbragstad> sweet
18:22:17 <knangia> cool !
18:22:35 <lbragstad> #action gagehugo and knikolla to start updating keystonemiddleware architecture doc and provide knikolla and unrahul with an updated keystonemiddleware architecture diagram
18:22:45 <topol> o/
18:22:50 <lbragstad> #undo
18:22:51 <openstack> Removing item from minutes: #action gagehugo and knikolla to start updating keystonemiddleware architecture doc and provide knikolla and unrahul with an updated keystonemiddleware architecture diagram
18:22:58 <lbragstad> #action gagehugo and knikolla to start updating keystonemiddleware architecture doc and provide knangia and unrahul with an updated keystonemiddleware architecture diagram
18:23:41 <lbragstad> knangia unrahul i assume once those things are done, we can start the next steps in the process
18:24:41 <knikolla> knangia: unrahul: which irc channel can we usually find you?
18:25:29 <unrahul> lbragstad: knikolla  we hang out mostly in #openstack-security
18:25:36 <gagehugo> cool
18:25:38 <knangia> +1 unrahul
18:25:44 <unrahul> you guys are welcome to join and ping us or anyone of us there for help
18:25:59 <knikolla> alright, added.
18:26:02 <lbragstad> nice - i just joined
18:26:09 <knangia> great
18:26:19 <lbragstad> awesome - well it sounds like we have a path forward
18:26:31 <lbragstad> gagehugo knikolla thanks for being awesome and helping with this
18:26:39 <unrahul> As this process is going on, it is a good idea to initiate discussions with the security team, by pining hyakuhei , who is the security PTL
18:26:47 <lbragstad> gagehugo knikolla do either of you have specific questions?
18:27:06 <knikolla> at the moment no
18:27:09 <gagehugo> lbragstad: not yet
18:27:15 <gagehugo> probably will later though
18:27:18 <lbragstad> gagehugo knikolla ack
18:27:30 <lbragstad> unrahul knangia do either of you have specific questions for us?
18:27:38 <knangia> hyakuhei can be a great assistance
18:28:25 <lbragstad> awesome
18:28:38 <gagehugo> knangia: noted
18:28:51 <unrahul> nop, nothing as of now, may be talking with someone in barbican can give more advice on how to do the new process as well as they just finished theirs
18:29:08 <knangia> not for now...probably later
18:29:11 <unrahul> I think redrobot is the barbican point of contact
18:29:29 <lbragstad> unrahul that makes sense, i assume we can hash that out in #openstack-security, too?
18:30:02 <knangia> yes
18:30:16 <lbragstad> I'll put a note on next weeks agenda to keep this in the fore front
18:30:32 <lbragstad> but I assume we'll come knocking when we have the diagram and everything ready to go
18:31:04 <lbragstad> unrahul knangia thanks for the time, answering questions, and being willing to help out
18:31:44 <unrahul> lbragstad: anytime, ping us if you guys need any further help, or anything.
18:31:49 <knangia> you're welcome :) glad to help
18:31:52 <lbragstad> unrahul will do
18:31:59 <gagehugo> will do!
18:32:17 <lbragstad> alright - moving on
18:32:19 <lbragstad> #topic PTG Topics
18:32:39 <lbragstad> last meeting we parsed a bunch of back logged specs and PTG items
18:33:06 <lbragstad> i've proposed some patches to update the keystone-specs repository accordingly
18:33:28 <lbragstad> we only have a couple topics left
18:33:29 <lbragstad> #topic PTG Topics: Decouple auth from API version
18:33:34 <lbragstad> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/decouple-auth-from-api-version.html
18:33:46 <lbragstad> notmorgan i know we had a pretty detailed discussion about this at the PTG
18:34:24 <lbragstad> notmorgan but since you have a better idea of how all that works, do you think the backlogged spec needs to be updated?
18:34:32 <lbragstad> given the current state of keystone?
18:34:38 <notmorgan> sooooo
18:34:44 <dstanek> i remember talking about this, but i don't remember if we were going to get it done this cycle
18:35:06 <notmorgan> basically what needs to happen is we need to implement the new auth route for keysotne at  /auth
18:35:09 <lbragstad> dstanek i'm not sure either - but I for sure want to capture notmorgan's PoV on it
18:35:26 <notmorgan> which takes an auth "version" or whatever we want to call it as part of the body/header/something
18:35:45 <notmorgan> then we need to wire up /v3/auth and /v2.0/auth into the mechanism
18:35:45 <lbragstad> the reasons for doing it seemed to make sense at the PTG and I think we should add them to the spec if we can, that way we don't lose the information
18:36:02 <notmorgan> so when those routes are hit, it converts to the expected form and passes across internally
18:36:26 <notmorgan> once that is done, we need to ensure ksa can talk to the new auth endpoint and know it's the new auth endpoint
18:36:42 <notmorgan> so GET /auth would need to produce something interesting
18:36:56 <notmorgan> it's not crazy nor super complex
18:37:09 <edmondsw> what are the reasons?
18:37:11 <notmorgan> it's just giving us flexability in auth without mucking with the crud interfaces
18:37:33 <notmorgan> because iterating on /v3/auth is going to _require_ microversions and microversions for auth on the v3 interface is a terrible idea
18:37:52 <notmorgan> it also allows us to maintain auth data if it doesn't need to change if we want to say do v4 api instead of microversions
18:37:53 <lbragstad> because.... ?
18:37:56 <edmondsw> this would require microversions as well, per the api guidelines
18:38:07 <notmorgan> edmondsw: no.
18:38:38 <knikolla> the new guidelines are pretty strict
18:38:52 <edmondsw> notmorgan go read https://review.openstack.org/#/c/421846
18:38:53 <notmorgan> the guidelines are terrible if we have to put microversions on an endpoint like auth
18:39:28 <knikolla> they basically want to microversion any change, for interop reasons
18:39:34 <notmorgan> microversions for CRUD interfaces is lazy and terrible.
18:39:43 <notmorgan> but is fine because we already lost that argument
18:40:29 <notmorgan> knikolla: then i think i need to just stop talking.
18:40:44 <notmorgan> scuttle the spec. just microversion things
18:41:08 <lbragstad> i thought there was discussion at the  PTG that made microversions questionable
18:41:33 <lbragstad> i mean - we already removed the microversion spec from our backlog
18:41:34 <edmondsw> lbragstad within the keystone room... but outside of keystone microversions are winning the day
18:41:52 <notmorgan> if we don't do microversions in keystone, moving auth is super important
18:42:00 <notmorgan> because the headache of v2->v3 was auth
18:42:03 <notmorgan> not the crud interface
18:42:17 <notmorgan> the fact we tied auth to the api crud api was a big mistake in v2.0
18:42:20 <notmorgan> and carried into v3
18:42:29 <notmorgan> (predates everyone here except maybe dolphm)
18:43:02 <notmorgan> if we do microversions in keystone and auth endpoint would need it too, i wont fight too hard for this
18:43:33 <notmorgan> i'll just let the folks doing microversions handle these cases. since it'll cover it
18:43:41 * notmorgan still thinks microversions are simply a terrible idea
18:43:56 <notmorgan> it comes down to keystone direction
18:44:09 <lbragstad> notmorgan would you be interested in documenting the reasons for decoupling auth from versions in the spec?
18:44:18 <lbragstad> notmorgan even if it's just a simple list?
18:44:40 <edmondsw> right... I don't disagree about microversions being awful. If keystone wants to hold out on not doing them, I'm fine with that. But we won't get that silly tag
18:45:05 <notmorgan> edmondsw: i'd rather keystone didn't have that tag
18:45:09 <dstanek> edmondsw: ++ for aiming for *not* having the tag
18:45:15 <edmondsw> :)
18:45:20 <knikolla> we're special
18:45:24 <notmorgan> lbragstad: the reasons are in the problem statement
18:45:28 <lbragstad> we're just a bunch of rebels
18:46:01 <lbragstad> notmorgan ok - so the spec is accurate, even with all the changes in keystone since it was proposed?
18:46:05 <notmorgan> yep
18:46:08 <lbragstad> s/proposed/merged to backlog/
18:46:09 <lbragstad> ok
18:46:10 <notmorgan> because auth hasn't really changed
18:46:20 <lbragstad> ok - cool
18:46:28 <notmorgan> the only things we might modify is make /catalog a top level bit as well
18:46:31 <notmorgan> or similar
18:46:44 <lbragstad> sounds like we can just leave it as is then for now
18:46:48 <notmorgan> yep.
18:47:04 <lbragstad> onward!
18:47:05 <lbragstad> #topic PTG Topics: Materialized Path for HMT
18:47:08 <notmorgan> but like i said, if we're doing microversions, i just wont push hard for this and would just say might as well scuttle the spec
18:47:36 <lbragstad> notmorgan sounds like we haven't gotten a definitive answer on that yet - but when we do i'll be sure to update accordingly
18:47:39 <lbragstad> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/materialize-project-hierarchy.html
18:47:55 <lbragstad> this has been in backlog for a long time
18:48:31 <notmorgan> i think we killed this a while ago
18:48:37 <notmorgan> like all the code for it
18:48:56 <lbragstad> yeah - i remember seeing an implementation for it somewhere,
18:49:00 <notmorgan> it was -2'd and abandoned because of some reason? also no one is championing it anymore
18:49:02 <lbragstad> it was in review for a long time/
18:49:05 <notmorgan> it's not a bad idea.
18:49:07 <notmorgan> afair
18:49:14 <lbragstad> no - it does sound useful
18:49:15 <dstanek> i think we may need to revisit the problem again because of limits
18:49:20 <lbragstad> right
18:49:25 <notmorgan> i don't remember why it was killed
18:49:35 <dstanek> not sure about the implementation though
18:49:48 <knikolla> dstanek: let's derive a new problem statement once we figure out limits
18:50:16 <dstanek> knikolla: there is no different in the fundamental issue
18:51:07 <lbragstad> from a performance perspective, we'll need this at some point if we do HMT I assume
18:51:18 <dstanek> we simply need a more efficient way to grab hierachy info... the limits work will just dictate what we do with it
18:51:34 <knikolla> dstanek: understood
18:51:43 <dstanek> this probably isn't needed this cycle though
18:51:48 <lbragstad> so it sounds like we need to follow up on this once we come to a more definitive conclusion of limits
18:52:34 <dstanek> i'd even go further to say we can follow up after we have a working poc for limits
18:52:43 <dstanek> then this would be an optimization
18:52:55 <knikolla> dstanek: ++
18:53:13 <lbragstad> #action keystone group to follow up on materialized path for HMT once we come to a conclusion on limits
18:53:23 <lbragstad> works for me
18:53:35 <lbragstad> i don't expect that to happen before Queens
18:53:40 <lbragstad> moving on
18:53:41 <lbragstad> #topic PTG Topics: Default Policy File
18:53:53 <lbragstad> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/policy-default.html
18:54:10 <lbragstad> with all the work antwash and ravelar have been doing, I don't think this is need anymore
18:54:10 <knikolla> this is obsolete by policy in code right?
18:54:23 <lbragstad> yeah - i think so
18:54:27 <edmondsw> yep
18:54:30 <notmorgan> yep
18:54:35 <ayoung> This grew out of the diesre to merge the curent ahd cloud sample approachs IIRC
18:55:00 <ayoung> Ah...no...that one can die
18:55:11 <lbragstad> #action lbragstad to remove policy default spec
18:55:20 <ayoung> I didn;t realize it was still around.  That was a vestige of the Dynamic policy effort
18:55:29 <lbragstad> nice - that was easy
18:55:30 <lbragstad> thanks for confirming
18:55:33 <lbragstad> moving on
18:55:34 <lbragstad> #topic Reviews
18:55:39 <ayoung> pretty sure I wrote it
18:56:01 <lbragstad> so we have some reviews to get around to - posted them here so that folks are aware
18:56:05 <lbragstad> password hashing in keystone: #link https://review.openstack.org/#/c/438808/ (bug: #link https://bugs.launchpad.net/keystone/+bug/1668503 )
18:56:05 <openstack> Launchpad bug 1668503 in OpenStack Identity (keystone) pike "sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm)
18:56:09 <lbragstad> Will need to be backported to all supported releases
18:56:13 <notmorgan> nope
18:56:17 <notmorgan> not being backported
18:56:28 <notmorgan> too difficult to do w/o disruption
18:56:34 <lbragstad> notmorgan isn't that what your note said?
18:56:42 <lbragstad> notmorgan aha - maybe i misunderstood then
18:56:46 <notmorgan> that is a master and forward change now
18:56:49 <notmorgan> the note was originally that
18:56:54 <notmorgan> it has changed post discussion in -keystone
18:56:55 <lbragstad> ok
18:57:03 <lbragstad> ok - cool
18:57:08 <lbragstad> either way, we'll need to get some eyes on it
18:57:10 <notmorgan> because it requires new config options etc
18:57:16 <notmorgan> really is not backportable.
18:57:21 <knikolla> true
18:57:36 <ayoung> make sure it does not break LDAP
18:57:38 <notmorgan> the ci failure it was seeing was unrelated
18:57:50 <notmorgan> ayoung: only affects password storage
18:57:53 <notmorgan> since ldap is non-write
18:57:54 <ayoung> got it
18:57:56 <notmorgan> doesn't matter
18:58:11 <lbragstad> couple more
18:58:12 <lbragstad> policy in code: #link https://review.openstack.org/#/q/topic:bp/policy-in-code+status:open+project:openstack/keystone
18:58:12 <lbragstad> oslo.policy descriptions: #link https://review.openstack.org/#/c/439070/
18:58:16 <notmorgan> the ci failure was testr binary/script in a non-expected location ftr
18:58:22 <notmorgan> so, please review.
18:58:23 <lbragstad> and finally - spec reviews
18:58:48 <lbragstad> we have a bunch of things proposed to specs, but it looks like most either need to be abandon or updated to reflect discussions had at the PTG
18:59:30 <lbragstad> spec proposal freeze will be in about 6 - 7 weeks
18:59:38 <lbragstad> but that's all I have
18:59:44 <lbragstad> thanks for coming everyone!
18:59:49 <lbragstad> #endmeeting