18:01:49 <dolphm> #startmeeting keystone
18:01:50 <openstack> Meeting started Tue Apr  8 18:01:49 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:53 <openstack> The meeting name has been set to 'keystone'
18:01:59 <topol> o/
18:02:00 <dolphm> #topic Reminder: Design summit session proposals open until April 20th
18:02:11 <morganfainberg> o/
18:02:28 <dolphm> so, we've got 21 proposed sessions the last i counted, and i'm aware of two more that are on their way to being proposed
18:02:36 <dolphm> we have 8 timeslots at the summit.
18:02:52 <bknudson> we need a longer summit
18:02:58 <dolphm> bknudson: i don't think we do :)
18:03:12 <dolphm> by my count, we should be able to fill those 8 nicely, by merging them
18:03:21 <dolphm> several proposals are near dupes, or closely related
18:03:22 <jamielennox> i haven't proposed anything related purely to keystoneclient (or seen anyone else do it) - i take it we are expecting one/
18:03:34 <dolphm> jamielennox: please do!
18:03:52 <dolphm> jamielennox: i'm planning for *something* client side to be one of those 8
18:04:07 <morganfainberg> ooh we got 8 slots?
18:04:09 <jamielennox> dolphm: i have less that is related purely to keystoneclient rather than all clients, but i'll propose and people can add to it
18:04:21 <bknudson> is one of the slots for the deployer feedback?
18:04:29 <gyee> jamielennox, keystoneclient seems like a good fit for cross-project, from integration standpoint
18:04:35 <dolphm> we should also have some dedicated space in the dev-lounge type area, so we can take certain topics there as well for smaller discussions
18:04:48 <dolphm> bknudson: so far, yes
18:05:10 <dolphm> gyee: cross-project track deadline is this week
18:05:12 <dolphm> for proposals
18:05:13 <ayoung> client, tokens, Federation (and LDAP) , Hierarchy (to include Policy),
18:05:24 <jamielennox> gyee: i did one that was cross-project: http://summit.openstack.org/cfp/details/205
18:05:32 <ayoung> bascially, I made a bunch of proposals that were supposed to be buckets
18:05:44 <jamielennox> (i need to do a better job of wording it)
18:05:46 <ayoung> Didn't make a client one
18:06:13 <dolphm> if there's not actual items that need to be designed / discussed, it won't be worthy of a session
18:06:16 <ayoung> Tokenless Keystone Operations  that one was for gyee
18:06:26 <gyee> client * middleware, especially middleware, auth_token is screaming out for refactoring
18:06:26 <dolphm> so a bucket alone isn't worth consideration without meaningful topics to fill it
18:06:46 <dolphm> gyee: "refactor" isn't something we need to fuss over at the summit, either
18:06:52 <bknudson> we were going to pull middleware to its own repo?
18:06:54 <jamielennox> gyee: oh there is plenty to do on the client - it's just what really needs discussing
18:07:04 <jamielennox> bknudson: that came up somewhere recently as well
18:07:19 <morganfainberg> bknudson, was goign to bring that up specifically at the end of the meeting today since we're early in a cycle we could do it.
18:07:22 <dolphm> bknudson: there's clearly some desire to - i'd be worried that we'd have to create a fourth repo as well, for things like cms
18:07:22 <ayoung> dolphm, right...those were the ones I knew we had something to talk about...feel free to close mine if there is a comparable other submission that is more explicit
18:07:26 <gyee> dolphm, jamielennox, I would like to see auth_token not putting stuff in the headers anymore
18:07:36 <gyee> should stash them into the environ
18:07:43 <dolphm> we'd end up with keystone, python-keystoneclient, keystonemiddleware, and keystonelib or something
18:07:48 <bknudson> dolphm: I don't think we've got a circular dependency
18:08:03 <morganfainberg> dolphm, that isn't a bad breakdown imo
18:08:07 <ayoung> python-keystoneclient,  would be deprecated, as we are moving to unified cli?
18:08:09 <bknudson> ohh, I guess keystoneclient would import middleware until it's moved.
18:08:19 <morganfainberg> bknudson, ++
18:08:26 <dolphm> everything would depend on keystonelib in that breakdown
18:08:44 <dolphm> ayoung: not yet; it'd be deprecated by python-openstacksdk if anything
18:08:45 <jamielennox> dolphm: what would keystonelib be as seperate from client?
18:08:47 <ayoung> although I might suggest that keystonelib should be keystoneclient, if only to keep the git history
18:08:57 <dolphm> jamielennox: keystone.common.cms for example
18:09:01 <jamielennox> because if it's session and auth plugins then it's more generic that that
18:09:17 <stevemar> sounds like we're having the client design session now :)
18:09:22 <lbragstad> wouldn't python-keystone client still be required since it is used but the unified client?
18:09:27 <dolphm> pretty much - this is a worthwhile summit session :)
18:09:30 <gyee> stevemar, yes sir indeed
18:09:31 <ayoung> jamielennox, anything that is common between client and keystoneserver I would think
18:09:39 <morganfainberg> lbragstad, yes, but it wouldn't be the same as the CLI it currently is
18:09:45 <jamielennox> ok - i'll put up a summit session for client today
18:09:47 <dolphm> lbragstad: yes, if/until it's replaced by python-openstacksdk
18:09:52 <dolphm> jamielennox: thanks
18:10:04 <lbragstad> morganfainberg: dolphm ok, makes sense
18:10:10 <ayoung> We also have cross-project summit sessions, right?
18:10:15 <dolphm> ayoung: yes
18:10:36 <ayoung> http://summit.openstack.org/cfp/details/95  is Python OpenStack SDK.
18:10:55 <gyee> dolphm, who make the decision on x-project sessions? PTLs?
18:10:55 <ayoung> http://summit.openstack.org/cfp/details/205  is Jamies
18:11:05 <ayoung> python-*client standardization
18:11:06 <dolphm> gyee: good question, i'm not sure
18:11:14 <nkinder> ayoung: there's also the one that jamielennox already mentioned (http://summit.openstack.org/cfp/details/205)
18:11:28 <dolphm> gyee: i don't even have access to moderate keystone sessions yet - it's still too early
18:11:28 <ayoung> nkinder, beat ya too it
18:11:30 <jamielennox> I'm hoping/assuming that there will be plenty of -sdk talk, i still haven't figured out what they want to be
18:11:30 <ayoung> heh
18:11:55 <dolphm> gyee: probably, yes, though
18:11:59 <bknudson> jamielennox: from the latest discussion sounded like the current clients just in one lib
18:12:00 <gyee> dolphm, k, please update us if you have more info on that, I'll try to dig around too
18:12:17 <dolphm> jamielennox: i think "everything to everyone" is the answer :-/
18:12:54 <ayoung> We might be able to punt on a Keystone specific talk in favor of "Hierarchical Multitenancy in Every Project"
18:13:00 <bknudson> openstacksdk has a loonnnggg ways to go
18:13:06 <dolphm> gyee: in the mean time, comment on sessions you're interested in, or not. feedback on summit.openstack.org (and the mailing list, etc) is really important for the whole selection process
18:13:14 <jamielennox> bknudson: yea i have been following but they are talking dolphm's everything approach and i don't think it's sustainable
18:13:32 <gyee> dolphm, thanks, will do that this week
18:14:17 <dolphm> that's also why it's too early to make too many guesses about what sessions will be accepted/merged/rejected -- there's not enough feedback yet for many sessions, and there are yet-to-be-proposed sessions to consider as well
18:14:49 <dolphm> on that note ...
18:14:51 <dolphm> moving on :)
18:14:54 <dolphm> #topic Reminder: Review Icehouse release notes
18:15:07 <dolphm> just a quick reminder to take a pass at:
18:15:08 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
18:15:21 <dolphm> there's been a few things added, and there's a few TODO's noted that need to be fleshed out
18:15:29 <dolphm> if you're familiar with those features, contributions very much welcome :)
18:15:40 <dolphm> most of them are in Upgrade Notes
18:15:46 <ayoung> dolphm, do contribution have to pass a bknudson code review?
18:15:54 <dolphm> ayoung: yes?
18:16:01 <topol> only ayoungs...
18:16:10 <morganfainberg> topol, ++ :P
18:16:27 <bknudson> I will probably fix speling errors if I see them.
18:16:49 <dolphm> i'll fix wiki syntax :P
18:16:53 <gyee> bknudson, urban dictionary words ok?
18:16:57 <ayoung> any TODOs that are egregious?
18:17:03 <topol> so is there just a place toa dd comments on the wiki or we all have edit access?
18:18:10 <dolphm> ayoung: see for yourself? nothing crazy IMO
18:18:25 <ayoung> dolphm, yeah, nothing jumped out at me....
18:18:26 <dolphm> topol: everyone should have edit access with an LP account
18:18:34 <dolphm> s/an/a/
18:18:54 <dolphm> anyway, let's talk about something more exciting!
18:18:57 <dolphm> #topic Security review
18:18:57 <topol> dolphm, K
18:18:59 <dolphm> nkinder: o/
18:19:32 <dolphm> nkinder: have a link to your mailing list discussion? i'm coming up empty handed
18:19:43 <nkinder> dolphm: sure...
18:20:13 <nkinder> http://lists.openstack.org/pipermail/openstack-dev/2014-April/032046.html
18:20:20 <dolphm> nkinder: thanks!
18:20:34 <dstanek> nkinder: i noticed that the wiki page was showing the source of algorithms as passlib. is that intentional? passlib actually uses the hashlib implementation if I remember correctly
18:20:35 <dolphm> hopefully everyone saw this, this is obviously a worthwhile effort :)
18:20:50 <ayoung> dstanek, that rings true
18:20:53 <nkinder> dstanek: PassLib does both
18:21:11 <nkinder> I read the code, and they implement their own rc4, etc.
18:21:18 <nkinder> ...but they do use hashlib too
18:21:23 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n26
18:21:36 <dstanek> i don't think they implement sha* though
18:21:46 <nkinder> dstanek: correct
18:21:52 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n110
18:22:03 <lbragstad> sha512
18:22:17 <bknudson> for the "Potential improvements" -- we're not planning to do those for icehouse?
18:22:18 <lbragstad> and http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n125
18:22:40 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n117    salted sha is ugly, but necessary for the LDAP simple bind approach.  Ideally, that would be replaced, but I think the only viable alternative is Kerberos
18:22:48 <gyee> nkinkder, is this an OSS initiative?
18:22:58 <nkinder> dstanek: perhaps it's not clear, but I was trying to point out that sha1 is used by PassLib (not necessarily implemented by)
18:23:01 <ayoung> bknudson, we are plannign on imporvindg from Eventlet to Apache HTTPD
18:23:13 <nkinder> ok, let's talk about it at a high-level instead of specific crypto details
18:23:15 <dolphm> dstanek: passlib does use hashlib, for example https://code.google.com/p/passlib/source/browse/passlib/handlers/md5_crypt.py
18:23:42 <nkinder> I'm trying to get projects interested in gathering and maintaining this sort of info from release to release
18:24:05 <morganfainberg> nkinder, ++
18:24:06 <lbragstad> nkinder: ++ oslo has a bunch of stuff too.. which may or may not get used in other projects
18:24:09 <nkinder> This is useful for OpenStack deployers of course, but it's also really good from a development standpoint
18:24:09 <dolphm> nkinder: is there any reason why this shouldn't be tracked in tree, and code reviewed along with the impacting changes?
18:24:09 <ayoung> ldap_hash_password  ... I assume that was only called if you create a user via the LDAP backend, which is not someth8ing I would expect a real deployment to do, but I've been surprised before.
18:24:38 <nkinder> Instead of just saying "we should all do this", I audited Keystone myself first to show how I think it might look.
18:24:53 <bknudson> dolphm: in doc/source ?
18:25:06 <dolphm> bknudson: yes. nkinder: wiki sounds like a decent place to get these docs moving, but we can enforce their maintenance in gerrit
18:25:08 <nkinder> dolphm: in tree is fine too
18:25:17 <bknudson> I like that
18:25:24 <lbragstad> me too,
18:25:25 <nkinder> dolphm: so first I want to see if there is interest from each project.  Sounds like there is for Keystone.
18:25:30 <topol> nkinder++ that is an important initiative youa re driving
18:25:40 <nkinder> Second is what form should the info be kept in (in git, wiki, etc.)
18:25:43 <bknudson> people are always asking for this info
18:25:50 <dolphm> nkinder: absolutely, it sucks not being able to refer people to docs like these :-/ (until now!)
18:25:56 <stevemar> wiki seems good enough for now
18:25:58 <nkinder> anyone can screw with the wiki, so it's not the best place for authoritative info
18:26:04 <nkinder> yeah, good for now though
18:26:09 <dstanek> tree is good for some stuff - but if you continue down this track we'll have a while bunch of attack vectors we need to document
18:26:27 <dolphm> dstanek: that's an interesting point...
18:26:31 <bknudson> there's another effort for the threat analysis
18:26:39 <ayoung> Security bugs got in Launchpad until we have a fix, obviously
18:26:49 <nkinder> yeah, this is more of a high-level instead of a full threat analysis
18:26:54 <dolphm> this effectively becomes a release deliverable if it's in-tree, rather than a best-effort community thing
18:27:07 <dstanek> so far this is really just code level implementation, but i can see whating to document lots of other stuff too
18:27:08 <nkinder> dolphm: well, I'd like to make it a release deliverable
18:27:09 <lbragstad> I think it would be important to keep it simple right off the bat, description of why we need the encryption, names of the hashes used, maximum key length/strength, is it end user configurable?
18:27:12 <stevemar> dolphm, good point
18:27:16 <ayoung> "go in"  man my typing is worse than usual today
18:27:23 <nkinder> lbragstad: +1
18:27:30 <lbragstad> something in a chart form
18:27:34 <bknudson> it'll be available here if in doc/source -- http://docs.openstack.org/developer/keystone/
18:27:37 <nkinder> Keep it simple so we can actually acheive the goals
18:27:44 <dstanek> lbragstad ++
18:27:45 <ayoung> It would be nice if we had ethercalc for charts
18:27:48 <lbragstad> someone can look up if pycrypto is used, and if an end-user can bump up the key strength
18:27:57 <dolphm> lbragstad: keeping it simple in the long run is important for maintainability :)
18:28:09 <topol> nkinder do we have any provenance information on what crypto libraries are used and who dveeloped them?
18:28:13 <nkinder> The tables shoudl really say what is used, and why (by what feature)
18:28:17 <stevemar> dstanek, even if it's in tree, it's not like we don't neglect the docs :(
18:28:30 <dstanek> stevemar: :-)
18:28:49 <nkinder> topol: all we really have is what I've collected on that page so far
18:28:55 <topol> nkinder, K
18:28:57 <ayoung> what about something under Anne Gentle's team instead of under keystone?  Seems like a cross product doc effort?
18:29:11 <nkinder> ayoung: for publishing, that would likely work
18:29:15 <bknudson> there's a security guide...
18:29:18 <dstanek> in-tree would probably be fine, but i can definitely see things that audit logs and other artifacts out of tree
18:29:24 <dstanek> s/that/like/
18:29:24 <dolphm> ayoung: they're already responsible for publishing keystone/docs
18:29:35 <nkinder> ayoung: but each project should own the info on their own project and keep it up to date as code changes are made
18:29:37 <bknudson> http://docs.openstack.org/security-guide/content/
18:29:44 <ayoung> then lets do it in tree
18:29:44 <dolphm> nkinder: ++
18:29:47 <lbragstad> nkinder: right,
18:30:04 <nkinder> We can then use that info to populate the Security Guide if we want to provide an overview of used crypto
18:30:21 <nkinder> ok, so in tree it is.  Any suggestions on format?
18:30:30 <dolphm> does anyone have any criticism of what's available on https://wiki.openstack.org/wiki/Security/Icehouse/Keystone currently?
18:30:31 <nkinder> markdown?  something else?
18:30:44 <nkinder> dolphm: I do :)
18:30:46 <dolphm> nkinder: docs/ uses RST already
18:30:55 <nkinder> dolphm: some things are missing or need to be filled in more
18:31:30 <nkinder> dolphm: but we can discuss those on IRC outside of this meeting
18:31:44 <dolphm> nkinder: i'd like to see Potential Improvements filed as Wishlist bugs and tagged with 'security'
18:31:55 <lbragstad> nkinder: when do we plan to have a format up?
18:32:14 <dstanek> dolphm: great idea - i'll start posting those after this meeting
18:32:16 <dolphm> nkinder: you can then link this doc to https://bugs.launchpad.net/keystone/+bugs?field.tag=security - rather than duplicating those in the doc
18:32:21 <nkinder> So the other thought is that we can use the security-impact keyword to flag when a code change requires an update
18:32:32 <dstanek> idea are flooding in :-)
18:32:46 <nkinder> dolphm: +1 on filing the improvements.  Those were just items that I had ideas on, so feel free to chime in with others.
18:33:03 <dolphm> nkinder: i'd rather the code change include the doc update AND include SecurityImpact ;)
18:33:07 <nkinder> lbragstad: I can work on a format, though I'm not familiar with RST
18:33:24 <nkinder> dolphm: yes, both in one patch would be ideal
18:33:32 <bknudson> nkinder: here's the link I use -- http://docutils.sourceforge.net/rst.html#user-documentation
18:33:34 <lbragstad> nkinder: ok, cool. I can help out with that too.
18:33:36 <nkinder> dolphm: then we can -1 changes that skipped updating the doc.
18:33:44 <dolphm> nkinder: ++
18:33:48 <nkinder> lbragstad: that would be much appreciated
18:34:15 <nkinder> did most of my audit look accurate to everyone?  Is there anything important that I missed?
18:34:22 <bknudson> lbragstad: we've got scans for the other projects, too?
18:34:42 <nkinder> bknudson: not yet.  I need to go around and evangelize that...
18:35:01 <dstanek> nkinder: only thing confusing to me where what implementation was used for algorithms
18:35:12 <dstanek> other than that i thought it was great
18:35:19 <nkinder> bknudson: I'm really hoping to get buy-in from everyone such that this can be a part of our normal release process
18:35:29 <dolphm> hrm, i also just realized this encompasses both keystone and keystoneclient (and some of this would be moved to keystonelib if that existed)
18:35:30 <topol> nkinder++
18:35:35 <nkinder> dstanek: any suggestions on how it could be represented to be more clear?
18:35:41 <ayoung> nkinder, as I mentioned before, the "Self signed certificates" approach needs to die
18:35:52 <nkinder> dolphm: yeah, they are kindof wrapped together
18:36:21 <dstanek> nkinder: i can't tell if we are using three different sha1 implementations or if there are three different wrappers to the same implemenation
18:36:27 <stevemar> dolphm, whys that an issue?
18:36:31 <dolphm> nkinder: this one wiki page should be split into python-keystoneclient/docs and keystone/docs then -- and probably cross-linked to each other since they're so closely related
18:36:41 <ayoung> stevemar, auditability
18:36:42 <nkinder> dstanek: ah, yeah.  The wiki table made that odd.
18:36:46 <dolphm> stevemar: because a client change shouldn't require docs in the keystone/ repo to be updated, for example
18:36:59 <ayoung> you want to make sure that, if there is an known issue in an implementation, you've updated the vulnerability
18:37:00 <nkinder> dstanek: it's all just sha1 (hashlib), but it was for threee different usages
18:37:07 <stevemar> we'll probably have a lot of duplication
18:37:12 <ayoung> updated beyond the vulnerability
18:37:28 <nkinder> stevemar: in what regards?  between projects?
18:37:57 <stevemar> if we split the wiki contents to keystone/docs and keystoneclient/docs
18:38:18 <nkinder> stevemar: yeah, that's why I avoided it and just called out the source files.
18:38:49 <nkinder> ...but it's going to have to be split if we keep the docs in tree
18:39:04 <stevemar> i guess so :)
18:39:19 <bknudson> can we backport doc updates?
18:39:27 <nkinder> ok, well next steps seem to be to work on the formatting, then we can decide how to organize it between repos.
18:39:36 <dstanek> nkinder: yeah, something like that works
18:39:40 <dolphm> bknudson: yes
18:39:53 <dolphm> bknudson: not sure if they'd be consumed that way though
18:40:11 <ayoung> dolphm, rc2 window is closed, right?
18:40:15 <topol> dolphm, whats the criteria for backporting doc updates? Just critical; stuff?
18:40:21 <morganfainberg> ayoung, yes
18:40:23 <dolphm> ayoung: yes
18:40:33 <nkinder> we can use wiki for Icehouse, and in-tree for Juno
18:40:35 <ayoung> dolphm, when do we expect rc2 announced, then?
18:40:49 <nkinder> Icehouse will largely be going back and reviewing what we've already done anyway
18:40:55 <bknudson> I don't know if we can get to havana keystone developer docs.
18:40:59 <dolphm> topol: there's no precedence in keystone, afaik - but i'd happily propose doc corrections & additions to stable-maintenance
18:41:19 <dolphm> ayoung: it was released this morning
18:41:23 <bknudson> http://docs.openstack.org/havana/ just links to http://docs.openstack.org/developer/keystone/
18:41:27 <ayoung> Ah...
18:41:31 <ayoung> need to catch  up on email
18:41:32 <dolphm> ayoung: i meant to mention it at the beginning of the meeting, but forgot to put it on the agenda
18:41:44 <annegentle> bknudson: mostly the keystone docs are common and embedded
18:41:44 <dolphm> ayoung: http://lists.openstack.org/pipermail/openstack/2014-April/006468.html
18:42:00 <stevemar> bknudson, then no need to backport!
18:42:15 <annegentle> bknudson: http://docs.openstack.org/admin-guide-cloud/content/ch-identity-mgmt-config.html
18:42:17 <ayoung> So....that is probably Icehouse....
18:42:32 <annegentle> bknudson: oh sorry you're talking about dev docs
18:42:45 <dolphm> annegentle: ++
18:43:01 <bknudson> annegentle: well, we had discussed whether to put the security notes in dev docs or other docs.
18:43:19 <nkinder> annegentle: yeah, this is security guide related as well.
18:43:27 <dolphm> annegentle: we're discussing backports for openstack/keystone/docs to stable/ branches, for the purpose of documenting security-relevant topics
18:43:42 <nkinder> annegentle: we're talking about having some security info from each project feed into the Security Guide.
18:43:47 <dolphm> annegentle: (for docs that don't exist in-tree yet, just on the wiki)
18:43:47 <annegentle> ah you won't get point-in-time publishing of dev docs
18:43:59 <annegentle> nkinder: cool, great.
18:44:17 <dolphm> annegentle: are you aware of any distros or anyone doing anything with stable/ dev docs?
18:44:35 <annegentle> dolphm: the only stable/relname docs are in openstack-manuals and it's just the install guide and the config ref. We could add the security guide though, just a matter of deciding on it
18:44:45 <nkinder> annegentle: I can chat with you offline about the idea to get your recommendations on the best way to do that from a format perspective (it's sort of the same thing we need to figure out for OSSNs).
18:44:54 <annegentle> nkinder: sure
18:45:20 <nkinder> annegentle: ok, I'll shoot you an e-mail on it.
18:45:20 <bknudson> I like the dev docs because it's easy to update with the code.
18:45:27 <bknudson> also, we can look at them on github
18:45:29 <stevemar> ++
18:45:35 <nkinder> bknudson: +1.  It will help to keep it in sync
18:45:39 <annegentle> bknudson: but security affects all of openstack and is more of an integrated project set of issues
18:45:45 <dolphm> bknudson: ++
18:46:03 <annegentle> bknudson: nkinder: prioritization and discipline around it keeps it in sync
18:46:06 <nkinder> I do want to see what other projects think as well, as they may have different ideas
18:46:40 <bknudson> annegentle: well, I also like the security guide because it's going to be consumed outside of developers
18:46:50 <dolphm> nkinder: if they have better ideas, please share :)
18:46:57 <dolphm> nkinder: definitely bring this up at the barbican meeting as well :D
18:47:01 <ayoung> ++
18:47:02 <nkinder> dolphm: will do!
18:47:21 <nkinder> I'm happy to see all of the interest in it!
18:47:37 <dolphm> sounds like we have some agreement here for now, and there's nothing left on the agenda for today, so:
18:47:43 <dolphm> #topic open discussion
18:48:02 <dolphm> 12 free minutes
18:48:03 <morganfainberg> Quick plug
18:48:17 <morganfainberg> sql collapse: https://review.openstack.org/#/c/78169/ this needs some feedback on the fk/constraint/index naming etc
18:48:52 <bknudson> +395, -4758
18:48:58 <dolphm> morganfainberg: i wanted to run db_sync 36 with and without that patch on mysql & postgres prior to +2'ing -- have you done either of those and compared sqldumps?
18:49:01 <morganfainberg> i'd like to implement consistent naming across the board, which requires a migration to sync all prodiuction deployments, but i want to get it right in that review as the base
18:49:04 <dolphm> bknudson: auto +2
18:49:16 <morganfainberg> dolphm, i did that when developing this.
18:49:31 <morganfainberg> dolphm, but... the FK / constraint / etc names are difference
18:49:41 <morganfainberg> and with SQLA and postgres there are oddities that require explicit naming
18:49:45 <dolphm> morganfainberg: if you have a diff handy, could you paste one?
18:50:01 <morganfainberg> dolphm, i'll need to re-run it, the diff came pre icehouse
18:50:06 <morganfainberg> dolphm, so i'll re-run and post the diffs
18:50:16 <jamielennox> i have a request for some client reviews please - they are stagnating again, we are back to the point where there are a few difficult ones to process so come find me if you are unsure of any reasoning
18:50:22 <topol> morganfainberg, whats the magic that allows you to compress so much???
18:50:36 <dolphm> topol: dropping support
18:50:37 <jamielennox> re-reading that it was way to gentle: do client reviews!
18:50:48 <morganfainberg> jamielennox, i expected less gentle this time :P
18:50:50 <ayoung> morganfainberg, did you run that against livetests for both mysql and postgresql?  bknudson can one of you IBMers confrim the DBishness of that smooshing?
18:50:51 <dolphm> topol: for essex and folsom
18:51:06 <topol> dolphm, thats awesome. so much less code to look at
18:51:13 <dolphm> topol: and less to maintain!
18:51:14 <morganfainberg> ayoung, i had no issues with the migrations working under mysql and postgres, that seems like all the _live_tests do
18:51:21 <gyee> jamielennox, I'll take a look
18:51:33 <topol> dolphm, I may actually look in that folder now :-)
18:51:35 <gyee> I also commented on the configurable hash algorithm review https://review.openstack.org/#/c/80401/
18:51:35 <dolphm> topol: this also means faster tox run times :)
18:51:38 <morganfainberg> ayoung, but before i went too much further i wanted to snag people for the FK / ix / ixu naming
18:51:40 <dolphm> topol: ha
18:51:48 <ayoung> morganfainberg, yeah....need to take another look at getting out sql unit tests running against the real databases again
18:51:49 <gyee> we need to embed the algorithm into token data
18:51:56 <bknudson> ayoung: I'll try it out with my db2 setup.
18:52:05 <dstanek> has anyone run the unit tests against mysql? i was having a bunch or problems with it
18:52:05 <morganfainberg> dolphm, not much faster. we don't migrate for most tests now we use sqlite reflection in memory
18:52:09 <ayoung> morganfainberg, FK naming should be in a DBMS specific manner, I think
18:52:19 <ayoung> dstanek, I have not tried in over a year
18:52:21 <bknudson> gyee: I'll take a look at embedding the algorithm.
18:52:29 <bknudson> gyee: why is that necessary?
18:52:31 <morganfainberg> ayoung, except that we can't use reflection if needed to interact with it then
18:52:36 <topol> we need to keep a record of the patch that replaces a huge chunk of code with a smaller replacement. And that person gets a prize every release
18:52:41 <nkinder> jamielennox: you need more of a mean-streak... ;)
18:52:44 <morganfainberg> ayoung, mysql would be _ibfkXX posgres is _fkey, etc
18:52:49 <gyee> bknudson, otherwise, it will break rolling upgrade
18:52:50 <dolphm> bknudson: you don't seem to be impacting /v3/OS-REVOKE/ ?
18:52:57 <ayoung> morganfainberg, yes, and its ug-ga-lee....
18:53:01 <morganfainberg> ayoung, a consistent naming convention would be good.
18:53:02 <topol> Sort of like the hourly high poker hand at the card room
18:53:15 <bknudson> dolphm: I haven't looked at OS-REVOKE... will do
18:53:17 <morganfainberg> ayoung, and there are times reflection use is important (notably in some migrations)
18:53:17 <dolphm> err, that's not where the revocation *list* lives...
18:53:30 <bknudson> dolphm: does it have token hashes?
18:53:37 <ayoung> morganfainberg, I'm ok with reflection use, I was not the one that protested it.
18:53:44 <morganfainberg> ayoung, i know.
18:53:50 <dolphm> bknudson: /v2.0/tokens/revoked is completely undocumented - ayoung: do we expose the token revocation *list* on v3?
18:53:57 <dolphm> ayoung: or just events?
18:53:58 <ayoung> BTW...if we change the token hash algorithm...all old tokens should be revoked....
18:54:06 <bknudson> there's no revocation list on v3... we've got the certs
18:54:13 <ayoung> dolphm, I thought just v2....let me confirm
18:54:31 <morganfainberg> ayoung, but anyway, i want something we can programatically interact with / validate if we choose.  anyway topic to be continued on gerrit review post meeting
18:54:46 <dolphm> bknudson: if there's no existing docs to update, go ahead and +A the client-side review
18:54:53 <ayoung> dolphm, V3 as well:  http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/controllers.py#n457
18:55:09 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/routers.py#n37
18:55:19 <bknudson> dolphm: I'm going to look into the hash algorithm in the tokens... does the middleware care?
18:55:29 <bknudson> it tries to hash the token right away to see if it's in the cache
18:55:30 <ayoung> bknudson, yes it cares
18:55:47 <gyee> bknudson, ^^ what he says
18:55:48 <bknudson> but this is before it's even validated it.
18:55:49 <ayoung> bknudson, might not be a real issue
18:56:05 <bknudson> this is before auth_token has validated the pki token
18:56:32 <bknudson> the revocation list will have the hash algorithm
18:56:36 <ayoung> if the middleware hashes the token...it would be wierd for anything other than a local memcached look up.  In theory, middleware could  skip PKI validation and do a remote verification
18:57:15 <gyee> bknudson, middleware should get the algorithm from token data, not configurable
18:57:24 <ayoung> that would take an explicit setting of a config value.  So if it hashed to MD5, but the serve was doing sha256, token validation would fail
18:57:27 <dstanek> ayoung: just ran against mysql and had over 2200 failures (can't create federation tables and unicode won't work)
18:57:27 <bknudson> ok, middleware gets a token hash -- it doesn't know what algorithm was used.
18:57:56 <ayoung> dstanek, ran what against mysql?  morganfainberg 's patch?
18:58:15 <dstanek> ayoung: the unit tests on master
18:58:18 <gyee> bknudson, you can tell be the length
18:58:21 <nkinder> ayoung: the hash algo. mismatch would be solved if we do what gyee suggests though, right?
18:58:38 <ayoung> ah...that might be as expected, dstanek but good to know....starting point for Juno cleanup
18:58:46 <ayoung> nkinder, yep
18:58:52 <nkinder> gyee: you could, though that's a bit hackish
18:58:54 <bknudson> if middleware gets a token hash it validates against the server.
18:58:55 <ayoung> nkinder, except that it would never fetch the revoc ation list
18:59:02 <bknudson> I don't think it cares about the hash then?
18:59:03 <ayoung> that is only done for PKI validation
18:59:08 <dolphm> time's up!
18:59:23 <bknudson> thanks!
18:59:26 <gyee> nkinder, if we only have to hash string, that's best we can do :)
18:59:27 <nkinder> thanks alL!
18:59:32 <dolphm> ayoung: https://bugs.launchpad.net/openstack-api-site/+bug/1304606
18:59:33 <gyee> s/to/the/
18:59:34 <uvirtbot> Launchpad bug 1304606 in openstack-api-site "Identity API v3 OS-PKI extension is undocumented" [High,Triaged]
18:59:34 <dolphm> #endmeeting