18:03:36 <dolphm> #startmeeting keystone
18:03:37 <openstack> Meeting started Tue Sep  3 18:03:36 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:37 <bknudson> what happens after? still have master?
18:03:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:40 <openstack> The meeting name has been set to 'keystone'
18:03:41 <dolphm> was pizza'ing
18:04:13 <dolphm> #topic feature freeze
18:04:22 <topol> hello just joined
18:04:30 <ayoung> So, I know we have henrynash 's Filter feature under discussion.  Before we get lost in that
18:04:39 <ayoung> anything else major that needs review
18:04:56 <gyee> ayoung, how about nachi's generic signature auth plugin
18:05:02 <gyee> would be nice to get that one in
18:05:03 <dolphm> Havana milestone 3 milestone-proposed is cut later today at which point features are late and a pain
18:05:08 <morganfainberg> https://review.openstack.org/#/c/43609/ if we want caching on assignment CRUD stuff (project, domain, role)
18:05:13 <dstepanenko> guys, what about centralized quota management in keystone? are we going to have it in havana?
18:05:14 <dolphm> the final milestone branch is cut tomorrow at which point feature freeze is in full effect
18:05:28 <dolphm> and that'll be representative of havana as a whole :D
18:05:29 <henrynash> morganfainberg: I approved that a short time ago
18:05:30 <gyee> yes, quota as well
18:05:38 <morganfainberg> henrynash, oh didn't see it. thanks
18:05:57 <ayoung> dstepanenko, that one was close, as I recall
18:06:07 <ayoung> post your review links here
18:06:08 <dolphm> dstepanenko: i missed thing meeting last week, but my understanding is that keystone-core felt it hadn't gotten enough attention during the milestone and wanted to postpone it
18:06:15 <dolphm> s/thing/the/
18:06:34 <dolphm> i saw that someone retargetted it to havana-m3
18:06:45 <ayoung> dolphm, I thin the discussion was more than that
18:06:59 <ayoung> it was under active development, and I was browbeating people into looking at it, IIRC
18:07:00 <dolphm> ayoung: can you summarize?
18:07:13 <gyee> would be nice to get someone from swift and nova to review the quota one as well
18:07:20 <dolphm> gyee: ++
18:07:22 <ayoung> dolphm, it is an extension, and needs to be disabled, but other than that, I thought it was pretty close
18:07:22 <gyee> they will be the first consumers I think
18:07:25 <dstepanenko> design -  https://review.openstack.org/#/c/37545, db part of code https://review.openstack.org/#/c/44878/1, api part of code - https://review.openstack.org/#/c/40568
18:07:40 <ayoung> ah..and needed the API review finished, too
18:07:55 <morganfainberg> dstepanenko, i think there is only one question i have on the API spec.  how do user quotas fit in / use case for them.
18:08:06 <ayoung> never put commas at the end of your urls. Correct grammar be damned
18:08:07 <dstepanenko> actually, I split patchset into 2 parts so that we can review it separately
18:08:20 <morganfainberg> dstepanenko, other than that, it looked good to me.  the patchsets were close imo
18:08:23 <dolphm> ayoung: my client handles it :)
18:08:39 <morganfainberg> ayoung, textual (my client) did the right thing :P
18:08:50 <stevemar> ayoung: youre on your own
18:09:05 <ayoung> stevemar, I represent the non l33t masses
18:09:25 <stevemar> dstepaneko, there are tests missing for both patches
18:09:41 <dolphm> as gyee suggested, i don't know if keystone-core can sufficiently represent the stakeholders of quota storage, so if we at least postpone it until icehouse-m1, that gives us some breathing room for stakeholder feedback to influence the api throughout icehouse
18:10:00 <dolphm> without stringently requiring backwards compatibility with havana
18:10:03 <ayoung> dstepanenko, that was not the review I remember...
18:10:05 <dstepanenko> morganfainberg I asked you via comments, but still admin can use user quotas for distributing resource between users. For example, admin can prevent some user use all the memory by creating as many cinder volumes as possible. In this case other users won't be able to create  their volumes because of memory exhaustion
18:10:19 <dstepanenko> this is first use case I see
18:10:46 <bknudson> who's the stakeholders for quota storage?
18:10:52 <dstepanenko> actually, our customes have many others and asks us to implement this feature
18:11:05 <ayoung> russellb, can you chime in as a rep from Nova on whether quota's are a must have for Havana?
18:11:21 <dolphm> bknudson: glance is the first on my radar
18:11:54 <ayoung> bknudson, swift, nova, cinder, and neutron all need quotas, but I don't think they will be able to consume it in the Havana time frame
18:11:55 <russellb> quotas for what
18:12:03 <ayoung> and glance...duh
18:12:16 <dolphm> russellb: centralized quota storage in keystone
18:12:17 <ayoung> russellb, the quoate storage in Keystone.
18:12:20 <russellb> ok
18:12:23 <bknudson> I wasn't sure if it was other openstack services or other users.
18:12:32 <russellb> well yeah, certainly can't consume anything new in havana at this point
18:12:36 <dolphm> ++
18:12:39 <russellb> so, not important to nova to have in havana
18:12:40 <ayoung> russellb,  https://review.openstack.org/#/c/44878/1 and https://review.openstack.org/#/c/37545,
18:13:10 <ayoung> dstepanenko, we ahve a lot of code that falls into that category.  Icehouse 1 is going to be a busy milestone release
18:13:14 <russellb> for that sort of thing, more important to land as early as possible in icehouse if you want it used in icehouse
18:13:43 <morganfainberg> i think that was the general gist of the conversation from last week's meeting
18:14:10 <jamielennox> i think icehouse, there are still -1s on api and code
18:14:23 <stevemar> jaimelennox ++
18:14:36 <ayoung> dstepanenko, do you have any reason that it *has* to be in Icehouse?  Assuming we could commit it as soon as the Havana/Icehouse branch happens, would that suit your needs
18:15:47 <bknudson> if it was in icehouse-m1 it could be core rather than extension
18:16:11 <morganfainberg> I would rather have a nice solid API spec that covers everything as well.  vs. something rushed that then has to maintain compat.
18:16:14 <dolphm> bknudson: i think the featureset should be core, for now
18:16:14 <dstepanenko> ayoung what concrete dates are we talking about?
18:16:40 <morganfainberg> the spec is close, but still i think warrants some discussion to make sure it hits the usecases.
18:17:14 <ayoung> dolphm, when do we open up for commits to Icehouse?
18:17:39 <jamielennox> bknudson, dolphm: core? why? what's wrong with it as an extension?
18:17:41 <dolphm> dstepanenko: there's no concrete date ... it's whenever we've satisfied our release blocking bugs that release-proposed is created and master is re-opened for icehouse
18:17:56 <ayoung> bknudson, Quota's should probably stay extension
18:18:03 <dolphm> bknudson: ahh, should be an *extension*! my mistake
18:18:17 <dolphm> jamielennox: ^
18:18:45 <ayoung> dstepanenko, assuming we go based on the Grizzly example...
18:20:09 <dolphm> alright, i'm going to target it to 'next' until we have an icehouse-m1 to target
18:20:33 <ayoung> dstepanenko, rc1 was tagged on  Mar 31
18:20:40 <ayoung> Er Mar 22
18:20:46 <dolphm> #action dolphm to postpone https://blueprints.launchpad.net/keystone/+spec/store-quota-data until icehouse-m1
18:21:03 <dolphm> #action release blockers
18:21:05 <dolphm> whoops
18:21:08 <dolphm> #topic release blockers
18:21:16 <dolphm> #link https://launchpad.net/keystone/+milestone/havana-3
18:21:21 <dstepanenko> ayoung so 9 days passed between this 2 dates, right?
18:21:43 <dolphm> I don't think any of the in progress bugs represent milestone release blockers? (if you feel otherwise, please correct me!)
18:22:08 <dolphm> but if any of those are unmerged by CoB today, i believe they should become release blockers for havana
18:22:14 <ayoung> dstepanenko, longer than that, I think.  The g3 date was Feb21st
18:22:28 <henrynash> dolphm: I'd like to try and fix #1201487
18:22:36 <ayoung> and RC was supposed to be Mar 14t
18:22:38 <dolphm> ayoung: you have two bugs that don't appear to be started
18:22:45 <henrynash> dolphm: assigned to me anyway
18:22:50 <ayoung> #link https://wiki.openstack.org/wiki/GrizzlyReleaseSchedule
18:23:01 <ayoung> dolphm, I'll update.  Working on them.
18:23:17 <ayoung> don't think either will really upste things if they get defered
18:23:21 <henrynash> dolphm: agreed
18:23:27 <dolphm> henrynash: i was looking at that earlier today... i'd love for that to be fixed
18:23:37 <henrynash> dolphm: I'll fix it
18:24:24 <dolphm> current list of release blockers:
18:24:26 <dolphm> #link https://launchpad.net/keystone/+milestone/havana-rc1
18:24:27 <ayoung> dolphm, should we discuss filtering?
18:24:35 <dolphm> feel free to tackle those or suggest more that should be added to the list! ^
18:24:45 <henrynash> ayoung: I think we should :-)
18:24:57 <dolphm> sure, but one more thing from the agenda first...
18:25:02 <dolphm> #topic Keystone-related documentation bugs
18:25:11 <dolphm> #link https://bugs.launchpad.net/openstack-manuals/+bugs/?field.tag=keystone
18:25:50 <dolphm> the DocImpact tag signifies you've merged a feature that should result in revised documentation. a bug is automatically filed and tagged with the relevant project...
18:26:12 <dolphm> please follow up on those bugs and revise the relevant docs
18:26:28 <dolphm> they're piling up on us, and keystone is only trailing nova in terms of the number of unresolved doc bugs
18:26:31 <jamielennox> that's cool, i didn't know that
18:27:01 <morganfainberg> ah cool.
18:27:09 <ayoung> henrynash, so, I've yet to see a solid explanation of why Filtering is safe, and without that, I am unwilling to put my name on it.
18:27:11 <morganfainberg> good to know that's how that works.
18:27:14 <dolphm> #topic code reviews for havana blueprints
18:27:31 <henrynash> dolphm: filtering?
18:27:35 <ayoung> I'm willing to back off if some other core devs step up and are willing to vouch for it
18:27:36 <dolphm> morganfainberg: merge conflict https://review.openstack.org/#/c/43609/
18:27:38 <dolphm> henrynash: sure
18:27:40 <henrynash> perhaps, first, I could summarises where we are
18:27:51 <morganfainberg> dolphm, trying to resolve, can't connect to gerrit atm
18:27:58 <morganfainberg> review is just hanging.
18:28:03 <henrynash> there were 3 main issues raised in the review:
18:28:07 <dolphm> #link https://review.openstack.org/#/c/43257/
18:28:09 <morganfainberg> s/review/git review/
18:28:29 <henrynash> 1) list limiting was combined with filtering - Fixed by splitting them out so can review separately
18:29:02 <henrynash> 2) Controller-Driver contract was muddied and unclear, used url semantics etc. - Fixed (although needs review)
18:29:37 <henrynash> 3) …and potentially the thorny one….is it safe to use SQL Alchemy filtering if the "valuye" of the where clause comes from a url
18:29:54 <henrynash> the last one is the main issue that ayoung has
18:30:18 <ayoung> henrynash, yeah, although I still think that we are violating the H2 API freeze, but tha was dolphm 's burning platform, not mine
18:30:27 <henrynash> how?
18:30:33 <dolphm> .filter_by(column=value) ?
18:30:37 <stevemar> morganfainberg: he was just giving you a heads up to rebase 43609
18:30:47 <henrynash> dolphm, yes
18:30:48 <jamielennox> i think issue 3 is ok so long as there is a hard upper limit on the number of returned items
18:30:49 <morganfainberg> stevemar, nod.
18:31:01 <dolphm> ayoung: henrynash's change doesn't expose any new functionality to the api
18:31:23 <ayoung> dolphm, I'll let you be the judge.
18:31:29 <gyee> henrynash, if you save the original query_dict in ListDirectives, you get my vote
18:31:51 <dolphm> ayoung: if you can perform filtering or anything against henry's change through the http api, please speak up and point it out
18:32:09 <henrynash> gyee: the __init__() takes the quer_dict as a param and builds the list directive
18:32:27 <gyee> henrynash, I need to lookup the original one
18:32:47 <gyee> henrynash, self.query_dict = query_dict
18:32:54 <gyee> that's all I need :)
18:33:31 <dolphm> gyee: for?
18:33:43 <gyee> dolphm, I have some custom drivers
18:34:26 <dolphm> gyee: drivers really shouldn't be consuming raw garbage from the http api
18:34:33 <henrynash> gyee: and you use the query string to pass them data?
18:35:04 <gyee> you only build query string from valid filters, I need to be able to extend it
18:35:13 <gyee> to support HP-specific filters
18:35:45 <gyee> competitive advantage, whatever :)
18:35:51 <dolphm> gyee: can you present a use case for what you're solving for after the meeting?
18:35:55 <henrynash> gyee: OK, let's discuss….but I'd like to get back to the BIG issue….of whether we are OK with using SQLA filtering
18:36:12 <gyee> dolphm, k
18:36:24 <ayoung> dolphm, are you comfortable with the current approach to the URL -> SQL transformation?  Do you feel like there has been sufficent Security review?  If so, add it to the review and I'll remove my -1
18:36:32 <ayoung> same goes for any other core devs
18:36:53 <dolphm> there's no demonstrated vulnerability against sqlalchemy, so concerns about injection are just blather
18:37:01 <henrynash> what I have done is included tests that try and break it by doing sql injection in the value field, so far it holds up
18:37:18 <bknudson> henrynash: those tests are great.
18:37:39 <morganfainberg> henrynash, fuzz testing? (I haven't looked closely at those tests)
18:38:09 <jamielennox> i think we should trust sqlalchemy's injection prevention, it's just a matter of checking that we use it all the time
18:38:19 <henrynash> bknudson: I would;t call them a total sweep of sql injection…but it does appear that SQLA is protecting itself against it
18:38:43 <ayoung> dolphm, not blather, just an attempt to make sure we are doing due diligence. I'm not saying there is an attack, just that we have confirmed that there is not one.
18:38:54 <morganfainberg> if sqla had an injection vuln, i think we'd not be the only ones seeing it or affected by it. it seems to be fairly sane about param binding etc.
18:39:00 <ayoung> or that we are appropriately using SqlA
18:39:11 <ayoung> fine...I'll remove the -1
18:39:19 <dolphm> ayoung: so ask for a review, investigate further, but blocking a review due to unjustified concerns doesn't make any sense
18:40:20 <morganfainberg> if it really is a huge concern, we could have henrynash withhold the actual filtering peice to Icehouse 1, just pass the query strings down to the drivers?
18:40:41 <morganfainberg> drivers would do nothing unless someone implemented a filtering implementation.
18:41:24 <henrynash> morganfainberg: if we can show there IS a huge concern, I'd agree with that….I just haven't seen the evidence yet...
18:41:24 <morganfainberg> that would, give plenty of breathing room on security review and proper use of SqlA
18:41:42 <morganfainberg> henrynash, i would agree, that is an if.
18:41:57 <dolphm> the assumption that filter parameters would come from the query string is (while reasonable), completely arbitrary and shouldn't be reflected in the driver interface
18:42:01 <henrynash> morganfainberg: it also means we can't limit the lists either (since you have to filter first before you limit)
18:42:05 <gyee> security is a process, software is a tool :)
18:42:26 <topol> gyee +1
18:42:48 <henrynash> dolphm: is that a comment on the new implementation or a general one?
18:42:58 <morganfainberg> henrynash, i am torn on the limit part, i don't like that the client has no knowledge of the limiting occuring, but defaulting it to off seems fine. (not a blocker imo)
18:43:11 <ayoung> I've removed the -1.
18:43:28 <dolphm> henrynash: in general
18:43:48 <henrynash> dolphm: Ok :-) and agree
18:43:57 <henrynash> dolphm: you convinced me of that
18:44:03 <dolphm> morganfainberg: i share that concern... but i understand a deployer wanting to set a reasonably high limit there (e.g. 1000)
18:44:09 <dolphm> in fact... we used to have that feature in diablo
18:44:19 <dolphm> it was dropped in essex and i haven't heard anyone complain
18:44:45 <henrynash> dolphm, morganfainberg: and we default to off, here too of course
18:45:01 <henrynash> (i.e no limit)
18:45:02 <dolphm> henrynash: setting a default limit *was* surprising though... so defaulting the feature to off should be mandatory
18:45:47 <morganfainberg> henrynash, as long as it is unlimited by default, i see no reason to block it.  if an operator wants to limit, that really becomes an explicit choice at that point
18:46:01 <dolphm> henrynash: (i think the limit was 1000, which was super non-obvious when results were returned in a random order, sorted client-side, and a specific entry appeared in the middle of the resultset appeared to be missing)
18:46:07 <henrynash> morganfainberg: it is unlimited by default
18:46:26 <dolphm> #topic open discussion
18:46:46 <bknudson> what's the version for havana (for use in man page, etc)? 2013.2?
18:47:00 <gyee> dolphm, henrynash, I need to query_string saved so I can support provider-specific filtering
18:47:34 <dolphm> i'm going to apologize right now -- i want to see RC1 go out the door happily bug free, so i'll be harassing keystone-core for bug fixes and reviews more than ever for the next couple weeks
18:47:49 <henrynash> dolphm: more power to you
18:48:04 <dolphm> morganfainberg: gyee: henrynash: bknudson: ayoung: sorry!
18:48:11 <morganfainberg> dolphm, hehe i'm ok with it
18:48:17 <dolphm> mostly for reviews
18:48:20 <ayoung> dolphm, fine by me
18:48:23 <topol> dolphm no need to apologize.  being the leader means having to be tough :-)
18:48:24 <gyee> ha, np, we'll be busy doing code reviews anyway
18:48:28 <bknudson> I hope it's bug free too.
18:48:41 <dolphm> bug fixes will come out of the woodwork this time of year
18:49:05 <dolphm> topol: community-elected cat herder*
18:49:14 <gyee> meow
18:49:20 <topol> yes, that too
18:49:38 <stevemar> cat herding is tough business
18:49:49 <ayoung> dolphm, Are we doing API freeze in I2?
18:50:12 <henrynash> ayoung:look ahead planning, I like it
18:50:27 <dolphm> ayoung: i'd like to discuss it again at the summit (did it work in havana? etc)
18:50:49 <topol> ayoung, I liked it as well.   Seemed like all of you were less stressed this time compared to the previous release
18:50:55 <dolphm> ayoung: assume yes based on precedent, but come to the summit with an opinion
18:51:05 <dolphm> topol: ++++++
18:51:08 <stevemar> topol ++
18:51:12 <ayoung> dolphm, OK,  so it is a wroking propsal, then?
18:51:15 <ayoung> working
18:51:25 <dolphm> ayoung: sure
18:51:29 <ayoung> We have a bunch of wrok poised for I1 already
18:51:34 <ayoung> KDS, QUotas, etc
18:51:50 <dolphm> i think featureproposalfreeze was also awesome, and given a bit more notice, i'd like to do it a week in advance for m1 and m2, and then 2 weeks in advance of m3
18:52:01 <gyee> and we're going to fix service catalog right?
18:52:05 <ayoung> might be nice to warn people that want things to go in , especially things that have already been discussed, like regions support
18:52:10 <ayoung> "start now"
18:52:24 <dolphm> gyee: yeah, i'd like to have a summit session to architect GET /v3/catalog
18:52:31 <gyee> +++++++++++++
18:52:59 <ayoung> dolphm, would be nice to get the summit Keystone proposals posted.
18:53:00 <dolphm> (cc: ayoung, morganfainberg) i filed a summit session on token revocation, mostly just so i could play with summit.openstack.org http://summit.openstack.org/cfp/details/5
18:53:12 <morganfainberg> dolphm, nice.
18:53:16 <ayoung> dolphm, nice
18:53:36 <gyee> what revocation?
18:53:54 <gyee> what happen to short-lived tokens?
18:53:54 <ayoung> gyee, instead of posting a list of revoked tokens
18:54:10 <dolphm> ayoung: i also found this which makes me sad http://www.google.com/patents/US20130125228
18:54:18 <ayoung> we post a list of criteria for determining if a token is still valid
18:54:31 <gyee> oh, wtf?
18:54:33 <dolphm> gyee: i wanted to put very-short-lived tokens on the list as a potential solution, but didn't see a bp for it
18:54:38 <morganfainberg> dolphm, isn't that basically TOTP?
18:54:43 <morganfainberg> oh oh
18:54:47 <morganfainberg> that is sad
18:54:50 <dolphm> yeah
18:54:55 <topol> why does the patent upset you?
18:55:23 <morganfainberg> at least google has a history of being nice to OSS projects (as i recall)
18:55:27 <jamielennox> how the hell did that get passed being filed in 2011?
18:55:30 <dolphm> topol: because it's patenting a viable solution to our token revocation woes
18:55:33 <ayoung> dolphm, short lived tokens are not a stand alone feature.  I think that they are dependent on some other features.
18:55:48 <topol> there must be prior art that blow that patent out
18:55:49 <ayoung> We can pull that all together into one session, though
18:56:13 <topol> its easy to get around patents
18:56:23 <stevemar> morganfainberg: it's not google though, its RIM
18:56:36 <ayoung> dolphm, https://blueprints.launchpad.net/keystone/+spec/delegation-workplans
18:56:43 <morganfainberg> stevemar, oh. misread.
18:56:51 <morganfainberg> stevemar, crud.
18:56:54 <topol> need to look at its process (flowchart) and then have a different flowchart
18:57:13 <ayoung> bascially, we need a way to tell a remote service "When the time comes to do something on my behalf, use this delgation mechanism"
18:57:28 <ayoung> then, a token doesn't ahve to live for the entire workflow
18:57:34 <topol> there must be prior art
18:58:10 <topol> token revocation is not new
18:58:26 <morganfainberg> ayoung, agreed.
18:58:34 <stevemar> sounds like topol is volunteering to do work/research :P
18:59:03 <ayoung> dolphm, so...maybe a session on the steps needed to reduce token lifespan, with both of those topics covered?
18:59:16 <topol> Ill go read the patent. then you need to explain to me your solution. Ideally the flowcharts are different
18:59:27 <dolphm> topol: the filing is a bit specific, but it's basically a broadly scoped form of https://blueprints.launchpad.net/keystone/+spec/revocation-events
18:59:52 <stevemar> dolphm: can we get an icehouse-m1 tag in launchpad?
18:59:52 <dolphm> ayoung: start running devstack with a shorter default token duration :)
18:59:58 <dolphm> ayoung: and then make it shorter again
19:00:05 <stevemar> dolphm: and start targetting blueprints?
19:00:10 <gyee> till someone screams
19:00:10 <dolphm> stevemar: that's up to ttx
19:00:28 <stevemar> kk
19:00:33 <dolphm> stevemar: rather, i think i could do that, but i don't want to step on ttx's toes
19:00:37 <jamielennox> there is a crowd sourced forum somewhere that's job is to dig up prior art on patents
19:00:39 <stevemar> :)
19:00:56 <ayoung> not too worried,  I don'
19:01:00 <dolphm> stevemar: he probably has a script to do it for all projects at once
19:01:00 <morganfainberg> jamielennox, it would be good to try and avoid that need.
19:01:00 <stevemar> dolphm: nudge ttx then :P
19:01:10 <ttx> dolphm: I do have such a script yes
19:01:10 <dolphm> stevemar: it's coming, i just couldn't tell you when
19:01:14 <ayoung> t think that we are going to end up using that particualr method anyway
19:01:26 <jamielennox> morganfainberg, of course
19:01:31 <stevemar> anddd we're over
19:01:42 <lbragstad> thanks all
19:01:54 <dolphm> ahh
19:01:57 <dolphm> #endmeeting