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