18:03:06 <morganfainberg> #startmeeting keystone 18:03:07 <openstack> Meeting started Tue Jun 30 18:03:06 2015 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:10 <openstack> The meeting name has been set to 'keystone' 18:03:19 <morganfainberg> so ... lbragstad you here? 18:03:30 <morganfainberg> can come back to tht 18:03:31 <lbragstad> morganfainberg: yes sir 18:03:35 <breton> o/ 18:03:36 <morganfainberg> oh bug report then 18:03:42 <morganfainberg> #topic Keystone Bug Report 18:03:44 <morganfainberg> lbragstad: o/ 18:03:52 <lbragstad> http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html 18:03:54 <dstanek> Here now 18:04:06 <lbragstad> most everything on list weeks list looks to be triaged 18:04:21 <lbragstad> so, that's a plus! 18:04:48 <lbragstad> I think there are only a couple that haven't been triaged, but I can go through those 18:05:08 <lbragstad> other than that, bugs looks pretty tame this week 18:05:29 <bknudson> is oslo.policy included in the list? 18:05:29 <morganfainberg> great 18:05:33 <morganfainberg> bknudson: no 18:05:35 <lbragstad> bknudson: it can be 18:05:37 <bknudson> and other oslo libs that we support 18:05:38 <morganfainberg> oslo.policy is an oslo project 18:05:44 <morganfainberg> but it probably should be in our list 18:05:49 <morganfainberg> we're the ones who mostly look at it 18:05:57 <morganfainberg> bknudson: like oslo.cache 18:06:02 <lbragstad> I'll take the action item to add it to our bug report 18:06:14 <lbragstad> so we have it on our radar (for people who use that report) 18:06:25 <morganfainberg> #action lbragstad to add oslo.policy and oslo.cache to keystone bug report 18:06:48 <morganfainberg> yay for relatively under control bugs 18:07:04 <morganfainberg> #topic Making devstack v3 friendly 18:07:08 <morganfainberg> jamielennox: o/ 18:07:24 <jamielennox> hello 18:07:52 <jamielennox> oh - right, umm there is a chain of reviews up for devstack that move everything over to v3 CRUD then v3 auth 18:08:12 <bknudson> awesome 18:08:19 <marekd> jamielennox: link please 18:08:26 <jamielennox> starting https://review.openstack.org/#/c/186681/8 18:08:42 <bknudson> it's got -1 18:08:46 <jamielennox> damn, first one has a -1 i thought that was like 4 patches in 18:09:06 <jamielennox> oh - wait 18:09:16 <jamielennox> that's cause the first couple got merged :) 18:09:56 <jamielennox> so was starting https://review.openstack.org/#/c/186678/4 18:10:20 <samueldmq> jamielennox: https://review.openstack.org/#/q/status:open+branch:master+topic:keystonev3,n,z 18:10:26 <bknudson> I've got some changes up for using clouds.yaml -- https://review.openstack.org/#/c/195786/ -- might make this a little easier 18:10:42 <jamielennox> there is a fix for glance -> swift to use v3 https://review.openstack.org/#/c/193422/ 18:10:59 <jamielennox> and i think when those two things happen we can get devstack to run with v2 disabled 18:11:23 <jamielennox> so not a tempest run, but at least get to the point where our v3 only gate job can start telling us things 18:11:35 <samueldmq> jamielennox: ++ 18:11:42 <morganfainberg> jamielennox: building devstack with v3 only apis 18:11:44 <morganfainberg> is a huge setp 18:11:46 <morganfainberg> step* 18:12:08 <morganfainberg> if we are at least that far - then we're not going to have to fight too hard on the tempest side really 18:12:14 <Steve_droid> Gonna be typing slowly 18:13:05 <jamielennox> morganfainberg: right, i figure we can find and fix real tempest bugs quickly, just hopefully it doesn't uncover too many mistakes in services 18:13:13 <morganfainberg> yeah 18:14:01 <david8hu> I thought samueldmq is done with migrating tempest to keystone v3? :) 18:14:49 <samueldmq> david8hu: no, I created a devstack gate job with v2 disabled, which is something jamielennox is using :) 18:15:11 <david8hu> samueldmq, cool. I see. 18:15:15 <samueldmq> david8hu: and will be used to detect issues with services using v3 once devstack can properly set up resources and tempest can run 18:15:15 <bknudson> samueldmq: devstack-gate job runs tempest? 18:15:34 <samueldmq> bknudson: it will, once devstack can set up its own resources using v3 only 18:15:43 <samueldmq> bknudson: which is the step jamielennox's right now 18:16:00 <samueldmq> bknudson: after that step we will be able to check for individual issues on services/clients 18:16:03 <jamielennox> bknudson: there is an experimental job on devstack, and on tempest from memory for devstack gate to run with v2 disabled 18:16:09 <samueldmq> jamielennox: correct me if I am wrong :) 18:17:01 <samueldmq> yeah, for example http://logs.openstack.org/84/186684/4/experimental/check-tempest-dsvm-neutron-identity-v3-only-full/ca5f300/ 18:18:16 <jamielennox> bknudson: so in addiition to clouds.yaml i need to figure out how to fix the accrc files, i had some work done that way but i don't know if i posted it for review 18:18:39 <bknudson> accrc? how many files do we need? 18:18:43 <jamielennox> or know if it would be acceptable just to switch everything over to v3 like that 18:19:27 <jamielennox> bknudson: i don't know, at the moment the way accrc files are generated it loops over every project and creates a file for every user with a role in that project 18:19:40 <bknudson> yikes 18:19:45 <morganfainberg> scary 18:19:50 <jamielennox> i expect if i suddenly make those files v3 it will break people 18:20:01 <bknudson> delete those files 18:20:09 <jamielennox> would love to 18:20:34 <jamielennox> i expect for the last patch in that chain where we actually turn over to v3 by default we will break some people anyway 18:20:39 <jamielennox> may need an announcement 18:20:47 <jamielennox> i'll figure that out with the devstack folks 18:21:14 <jamielennox> anyway - i think that's all 18:21:32 <jamielennox> (not sure how this topic got in the meeting points) 18:21:42 <Steve_droid> I wonder how many ppl rely on the accrc file 18:21:42 <Steve_droid> ++bkudson, delete them 18:22:11 <marekd> these are openrc files so you source them and use devstack? 18:22:26 <bknudson> use clouds.yaml instead 18:22:30 <jamielennox> marekd: not really openrc 18:22:44 <jamielennox> but when you finish devstack you get like accrc/admin/admin that you can source 18:22:46 <Steve_droid> Marked yes 18:23:29 <morganfainberg> so it sounds like we have some cleanup to do 18:23:33 <morganfainberg> on devstack and some research 18:23:40 <morganfainberg> but the work is moving forward 18:24:03 <morganfainberg> jamielennox: maybe we need to make v3 versions of those files to start with 18:24:07 <morganfainberg> as crappy as that is 18:24:17 <morganfainberg> we should bug the devstack folks on that front 18:24:37 <jamielennox> i guess the issue is no-one really knows who relies on current behaviour 18:24:56 <morganfainberg> so lets plan to make v3 versions of those 18:24:58 <bknudson> does devstack say they have a stable API? 18:25:09 <morganfainberg> bknudson: no 18:25:10 <bknudson> it's supposed to be opionated 18:25:11 <jamielennox> given that we wont actually turn v2 off in devstack for quite a while i was thinking i could just add some domain properties to those files 18:25:14 <bknudson> opinionated 18:25:28 <morganfainberg> bknudson: we could just make v3 versions 18:25:28 <jamielennox> it won't affect us running v3 only gate jobs for quite a while 18:25:29 <bknudson> so if it's our opinion that you don't use accrc files then don't make them 18:25:34 <morganfainberg> or make v2 versions? 18:25:36 <Steve_droid> If someone aside from infra relies on devstack they are going to have a bad time 18:25:38 <morganfainberg> if v2 is enabled 18:25:58 <morganfainberg> anyway. jamielennox check w/ dtroyer and ianw and the other devstack folks 18:26:13 <morganfainberg> but i'd opt for just making them v3 rc files 18:26:15 <morganfainberg> peronsally 18:26:16 <jamielennox> Steve_droid: right - we are already at the point with plugins where i'm not sure if the changes i've made so far are going to end up breaking people 18:26:18 <morganfainberg> if we can get away with it 18:26:57 <bknudson> use clouds.yaml instead 18:27:06 <bknudson> the v3 rc file could just set OS_CLOUD 18:27:47 <bknudson> it'll be easier to just set OS_CLOUD than source an rc file 18:28:13 <Steve_droid> ++ 18:28:31 <jamielennox> bknudson: sure, i'm not too worried about this at the moment the first goal is to get tempest running with v3 only and we worry about devstack users later 18:28:47 <jamielennox> i'd be happy to consider all the accrc files deprecated 18:30:11 <morganfainberg> #action jamielennox to look into depecating accrc files and alternatives 18:30:14 <morganfainberg> ok moving on 18:30:25 <morganfainberg> i think there is some external work to do 18:30:34 <morganfainberg> but we have some direction 18:30:39 <morganfainberg> #topic Progress on keystoneauth & other repos 18:30:45 <morganfainberg> jamielennox: o/ any updates? 18:31:25 <marekd> morganfainberg: i am still waiting with this to be aproved - it's on a list of projec to be renamed when they schedule gerrit downtime. (https://review.openstack.org/#/c/190631/) 18:31:33 <jamielennox> umm, keystoneauth is moving along, i'm still trying to figure out the split loading from the plugins themselves 18:31:39 <morganfainberg> marekd: ok 18:31:48 <jamielennox> there is an issue with the gate job for ksc that relies on ksa 18:31:55 <marekd> morganfainberg: one more thing - why do we hav enow keystonauth1 ? 18:32:01 <morganfainberg> jamielennox: possibly because of the namespace change? 18:32:12 <marekd> what shall i put in the code? from keystoneauth or keystoneauth1 ? 18:32:13 <morganfainberg> marekd: because we're supporting side-by-side major versions 18:32:21 <morganfainberg> keystoneauth1 is the first release of keystoneauth 18:32:27 <morganfainberg> next major release will be keystoneauth2 18:32:28 <jamielennox> morganfainberg: yes - i didn't think it would matter because it's supposed to be pulling keystoneauth from git 18:32:42 <bknudson> does keystoneauth-saml2 also need 1 on the package? 18:32:43 <morganfainberg> jamielennox: except the whole namespace changes now. 18:32:50 <marekd> when will be next major release? and who will be supposed to use keystoneauth2 ? 18:32:54 <jamielennox> but for whatever reason it's getting the pypi version instead and that's still on the old namespace 18:33:04 <jamielennox> marekd: hopefully never 18:33:05 <morganfainberg> marekd: no plans for major release #2 18:33:10 <morganfainberg> but this is future proofing 18:33:12 <marekd> morganfainberg: ok. 18:33:24 <marekd> jamielennox: morganfainberg so for now shall i start importing from keystoneauth1 ? 18:33:29 <jamielennox> so for example https://review.openstack.org/#/c/196479/1 is failing 18:34:21 <jamielennox> i got as far as determining why they are failing but not yet determining why it's not pulling from git as expected 18:34:27 <jamielennox> because i'm sure it used to 18:34:35 <bknudson> where does that branch get its keystoneauth from/ 18:34:36 <bknudson> ? 18:34:39 <bknudson> pypi? 18:34:57 <morganfainberg> bknudson: git 18:35:02 <morganfainberg> directly 18:35:08 <jamielennox> so it's supposed to be git https://github.com/openstack/python-keystoneclient/blob/feature/keystoneauth_integration/requirements.txt#L9 18:35:08 <bknudson> http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/requirements.txt?h=feature/keystoneauth_integration 18:35:09 <bknudson> ah 18:35:37 <jamielennox> but it appears to be from pypi 18:35:38 <jamielennox> http://logs.openstack.org/79/196479/1/check/gate-tempest-dsvm-neutron-src-python-keystoneclient/b1d809b/logs/devstacklog.txt.gz#_2015-06-28_23_16_19_032 18:36:09 <bknudson> weird 18:36:24 <morganfainberg> something to chase down 18:37:02 <jamielennox> i would like to start getting those ksc on ksa patches merged as i don't want to consider keystoneauth stable until we know we can offload most of ksc to it 18:37:21 <morganfainberg> jamielennox: sure. 18:38:18 <morganfainberg> so we need eyes on those reviews 18:38:37 <morganfainberg> #action please review keystoneauth integration patches 18:38:43 <morganfainberg> #undo 18:38:44 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x8fb4250> 18:38:59 <morganfainberg> #action keystone developers please review keystoneauth integration patches 18:39:07 <morganfainberg> #topic Review policy update 18:39:11 <morganfainberg> bknudson: o/ 18:39:47 <bknudson> morganfainberg: I've got a couple of reviews out that hope to clarify that some things can be left up to the developer 18:39:58 <bknudson> https://review.openstack.org/#/c/194906/ -- Document update sample config up to developer 18:40:18 <morganfainberg> the only reason i don't want the sample config to be *in* the same review as code changes is because we've had massive rebase issues in the past 18:40:25 <bknudson> https://review.openstack.org/#/c/195335/ -- Document use of wip up to developer 18:40:32 <Steve_droid> I'm still hoping to automate that via a job 18:40:33 <bknudson> we had one review that had rebase issues. 18:40:39 <morganfainberg> if everyone else would rather make it up to the dev, i'll just abstain and not really care 18:40:50 <morganfainberg> bknudson: this was at the end of last cycle 18:40:54 <bknudson> y, so this is just to clarify whether it's up to the developer or not 18:41:11 <morganfainberg> we had a bunch of them. but like i said, i'll happliy defer to the rest of the team here. 18:41:16 <morganfainberg> on both counts 18:41:23 <morganfainberg> i don't feel strongly on WIP either 18:41:25 <bknudson> if cores don't think it should be up to the developer then I'll change the reviews to say it's not up to the developer instead 18:41:47 <morganfainberg> cores- please vote those 18:41:52 <henrynash> I think updating the sample config should be up to teh developer 18:41:55 <marekd> bknudson: whatever it is - just let's be verbose and make sure readed knows exactly what is the intention. 18:41:58 <bknudson> I think if people don't feel strongly one way or the other then let's leave it up to the developer 18:42:25 <henrynash> and reviews should -1 if a config file change is being put in with a sample updated (basically…the way it used to be) 18:42:29 <gyee> I am struggling with the wip decorator 18:42:33 <gyee> here's an example, https://review.openstack.org/#/c/187899/9/keystone/tests/unit/test_v3_protection.py 18:42:38 <gyee> line 994 18:42:55 <gyee> the API hasn't been developed yet so the code may not be correct 18:43:26 <gyee> so its essentially dead code at the moment 18:43:34 <gyee> I would rather not have them for now 18:43:40 <marekd> i liked wip too 18:43:50 <henrynash> sometimes wip is useful, other times I think it is more clear to really show the actual point in the test method where a failure is expected 18:44:17 <gyee> so wip is replacing TODO or FIXME? 18:44:34 <morganfainberg> ok so, i think we should be voting on those patches. if you want it to be more open - +1/+2 them 18:44:53 <morganfainberg> if you want ot be more restrictive -1 them. please let bknudson +A once we've let people vode 18:45:12 <morganfainberg> bknudson: feel free to +A at the end of the week provided enough +2s are there and outweigh the -1s 18:45:31 * morganfainberg is fine with it going either way 18:46:03 <topol> henrynash +++ 18:46:06 <dstanek> gyee: wip is different; it's really for replacing a skip 18:46:32 <gyee> so wip is for tests only? 18:46:50 <marekd> gyee: that's my understanding 18:47:05 <henrynash> dstanek: …or an explict assertRaises() with a comment as to “here is the bug I am going to fix in the next patch" 18:47:07 <david8hu> How does wip know the bug is fixed or develper has to going in and remove wip? 18:47:36 <samueldmq> david8hu: wip passes if the test fail, and fail if the test passes 18:47:55 <dstanek> henrynash: right, if otherwise the test should pass by just removing the wip 18:48:17 <dstanek> gyee: tests it's a testing tool from the TDD/BDD world 18:48:27 <dstanek> s/tests/yes,/ 18:48:49 <gyee> alrighty then 18:49:09 * gyee vote for +0 instead of -0 18:49:17 <morganfainberg> ok anyway 18:49:33 <morganfainberg> #action keystone-core vote on the reviews for policy (sample config and WIP) 18:49:38 <morganfainberg> #topic Dynamic Policies - Current Status and Scope for Liberty 18:49:54 <samueldmq> hi 18:49:58 <david8hu> hello 18:50:03 <morganfainberg> htruta: sorry we'll likely need to defer your topic for next week unless this goes quickly 18:50:13 <morganfainberg> htruta: my apologies 18:50:17 <samueldmq> last week I had a couple of conversations with morgan and adam about the scope for L 18:50:22 <samueldmq> morganfainberg: trying to be quick 18:50:26 <htruta> morganfainberg: it'd be quick 18:50:37 <htruta> but we can discuss in openstack-keytone later 18:50:38 <morganfainberg> htruta: depends on samueldmq 18:50:40 <morganfainberg> aye 18:50:42 <samueldmq> so, basically, we're adding the capability of dynamic fetching of policies in endpoints 18:50:43 <morganfainberg> samueldmq: go 18:50:45 <david8hu> wip 18:50:49 * samueldmq runs 18:51:02 <samueldmq> so, i)policy overrides occur at keystone 18:51:10 <samueldmq> ii) middleware fetches and cache the policy 18:51:21 <samueldmq> iii) using the oslo.policy libreary to overlay the local policy file 18:51:24 <bknudson> auth_token middleware? 18:51:25 <samueldmq> there are 3 respective specs 18:51:39 <samueldmq> oslo.policy doing the policy overlay 18:51:40 <samueldmq> #link https://review.openstack.org/#/c/196753/ 18:51:42 <samueldmq> ksmiddleware doing fetch and cache 18:51:44 <samueldmq> #link https://review.openstack.org/#/c/134655/ 18:51:45 <bknudson> or middleware after auth_token? 18:51:46 <samueldmq> keystone server associating and delivering policies by url 18:51:48 <samueldmq> #link https://review.openstack.org/#/c/192422/ 18:52:02 <gyee> bknudson, before auth_token as endpoint constraint depends on it 18:52:15 <samueldmq> bknudson: I think it will be a separate middleware filter, as suggested by morgan, need to visit this point 18:52:38 <samueldmq> I've updated the oslo and ksmiddleware specs, I will be addressing the keystone one until tomorrow 18:52:39 <ayoung> Na 18:52:39 <samueldmq> and then.... 18:52:49 <samueldmq> sending the FFE request to the ML 18:52:52 <ayoung> while separate would be cleaner...harder to deploy 18:52:59 <samueldmq> I think that's all 18:53:01 <david8hu> samueldmq, for policy by url, we need to consider additional cases that I commented on yesterday and today. 18:53:13 <ayoung> so, much as it pains me to drive toward it, its probably going to end up in auth_token 18:53:16 <bknudson> sounds like it might as well just be part of auth_token 18:53:22 <samueldmq> david8hu: sure, I 'll take a look at then 18:53:26 <samueldmq> bknudson: makes sense 18:53:35 <david8hu> thx 18:53:36 <samueldmq> so please review and leave comments :) 18:53:45 <gyee> auth_token is way overloaded already 18:53:51 <samueldmq> and for an overview reference 18:53:52 <samueldmq> see https://wiki.openstack.org/wiki/DynamicPolicies 18:54:06 <bknudson> auth_token might need some refactoring 18:54:24 <samueldmq> morganfainberg: I'd like to have more time, but I think I covered what I wanted .. letting people know about it .. we can move on 18:54:28 <ayoung> gyee, agreed, but we are cleaning up the architecture. I could see an approach that says there is a generic python middleware that lumps it all together 18:54:36 <jamielennox> i think this should be it's own middleware 18:54:38 <ayoung> but the sperate pieces could be deployed stnad alone as well 18:54:42 * morganfainberg is a fan of not making auth_token do everything 18:54:53 <ayoung> jamielennox, *should* only from a code cleanliness standpoint 18:54:55 <marekd> morganfainberg: so different middlewares? 18:54:57 <jamielennox> it's no harder to deploy than any other middleware we've added and there have been a few 18:55:05 <jamielennox> ayoung: mainly sure 18:55:08 <ayoung> lets treat auth_token as a facade for multiple middlewares 18:55:09 <gyee> jamielennox, exactly 18:55:11 <bknudson> if its its own middleware then it'll need to get the auth config again 18:55:15 <morganfainberg> marekd: thats my choice, but it's just from a separation of concern aspect 18:55:27 <jamielennox> bknudson: auth config? 18:55:34 <gyee> it would be paste.ini 18:55:37 <bknudson> jamielennox: config for how to talk to keystone 18:55:42 <jamielennox> oh - right 18:55:54 * morganfainberg avoids making a bad joke. 18:55:55 <bknudson> although we've been talking already about some middleware for that too 18:56:02 <marekd> morganfainberg: so one day it woud go for instance auth_token -> kmw-dynamic-policy - ksm-k2k for instance? 18:56:06 <bknudson> since nobody wants to use global CONF 18:56:25 <morganfainberg> marekd: possibly 18:56:28 <jamielennox> bknudson: so we need a way to pass down the plugin that auth_token middleware creates? 18:56:50 <bknudson> jamielennox: we can't pass it down since the policy middleware needs to be first 18:57:09 <bknudson> maybe we need another middleware that generates the plugin that's before both of them 18:57:25 <jamielennox> why does policy need to be first? 18:57:38 <bknudson> (01:52:02 PM) gyee: bknudson, before auth_token as endpoint constraint depends on it 18:57:42 <gyee> jamielennox, because we need it to enforce endpoint constraint 18:57:53 <morganfainberg> 2m left 18:58:21 <jamielennox> why don't we make endpoint constraint enforcement part of the policy middleware then 18:58:40 * jamielennox was arguing for it being seperate from auth_token anyway 18:58:42 <ayoung> jamielennox, that is where it belongs 18:58:50 <morganfainberg> 1m 18:58:57 <gyee> jamielennox, ayoung, no argument here 18:59:05 <samueldmq> ++ 18:59:13 <gyee> 30 seconds 18:59:21 <ayoung> jamielennox, I just want to avoid the deployment issues 18:59:21 <morganfainberg> #endmeeting