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