18:03:27 <dolphm> #startmeeting keystone
18:03:28 <openstack> Meeting started Tue Jul  1 18:03:27 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:31 <openstack> The meeting name has been set to 'keystone'
18:03:33 <dolphm> #topic Update on oslo libraries
18:03:38 <dolphm> bknudson: o/
18:03:49 <bknudson> ok, not a whole lot to say but the oslo team are starting to release libs
18:04:07 <bknudson> unfortunately they release with an alpha release and then I can't add it to global requirements
18:04:13 <bknudson> there was a note to the mailing list about this
18:04:15 <dolphm> does that mean -incubator is dying?
18:04:35 <bknudson> I think there are some things that will be in -incubator still
18:04:35 <morganfainberg> dolphm, yep.
18:04:36 <morganfainberg> dolphm, slowly
18:04:38 <bknudson> and new stuff can go there
18:04:39 <morganfainberg> bknudson, ++
18:04:45 <bknudson> but we'll have
18:05:01 <bknudson> - fixture moved to oslo.config (reviews out there)
18:05:05 <bknudson> - oslo.i18n
18:05:15 <dolphm> had a conversation recently about a (potentially) a new oslo incubator module -- would that just become it's own lib immediately instead?
18:05:17 <bknudson> - oslo.utils
18:05:32 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039089.html
18:05:41 <lbragstad> bknudson: was that the right thread?
18:05:46 <bknudson> oslo.utils has the import function that we use for managers
18:06:20 <bknudson> lbragstad: thanks, that's the link. I hadn't seen the latest update.
18:06:39 <bknudson> so I think that's it for the update...
18:06:47 <bknudson> kind of blocked by having to redo the entire infrastructure
18:07:14 <bknudson> dolphm: I think it depends on how stable you would consider the interface whether it goes to incubator
18:07:41 <bknudson> there has been an oslo lib where they didn't go to incubator first (vmware)
18:07:57 <dolphm> so, starting in incubator is still the default path
18:08:06 <bknudson> dolphm: I think so.
18:08:12 <dolphm> cool
18:08:31 <dolphm> well
18:08:35 <dolphm> #topic open discussion
18:08:35 <morganfainberg> dolphm, afaict the idea is move things out of incubator faster now that there is a set pathc.
18:08:37 <bknudson> but we already have a lot less code in keystone due to loss of db.session
18:08:46 <morganfainberg> dolphm, ooh i have something for open discussion!
18:09:01 <dolphm> morganfainberg: well it's open...
18:09:05 <morganfainberg> 2 things
18:09:06 <morganfainberg> Keystonemiddleware!
18:09:10 <dolphm> yay!
18:09:30 <dolphm> there was a devstack review blocking it's release -- did that merge?
18:09:36 <morganfainberg> as soon as it merges into dev stack  we can have a release (or well things): https://review.openstack.org/#/c/102326/
18:09:43 <morganfainberg> it's approved and just fighting with gate
18:09:46 <bknudson> btw, we already have a change to auth_token tests in keystoneclient that now needs to be made in keystonemiddleware,too
18:10:32 <bknudson> https://review.openstack.org/#/c/99846/
18:10:51 <morganfainberg> ok
18:11:02 <bknudson> I've got changes lined up to get the other projects using keystonemiddleware
18:11:05 <morganfainberg> well need to get that ported across
18:11:08 <morganfainberg> bknudson, ++
18:11:26 <bknudson> https://review.openstack.org/#/q/status:open+branch:master+topic:keystonemiddleware,n,z
18:11:33 <dolphm> can't we just nuke tests in keystoneclient?
18:11:46 <dolphm> in favor of 'ensure the import from keystonemiddleware works'
18:11:54 <bknudson> we don't import
18:11:56 <jamielennox> not until we remove it i think
18:12:05 <morganfainberg> dolphm, well, we can't do that import due to circular deps
18:12:11 <topol> bknudson, VERY COOL!!!
18:12:14 <morganfainberg> dolphm, we'd need to break apart ksc more than it is to do that
18:12:17 <jamielennox> still don't want to break existing
18:12:35 <dolphm> morganfainberg: ah, forgot about that.
18:13:10 <morganfainberg> and we might make some people very sad if we broke apart and added a new package dep  (read: havana / icehouse deployments)
18:13:40 <morganfainberg> we're going to need to hold middleware in ksc (at least an old version) probably until L releases.
18:13:45 <morganfainberg> at the very least K.
18:14:11 <jamielennox> morganfainberg: 2.0
18:14:11 <morganfainberg> but it is mostly isolated from the rest of keystoneclient, so maintaining it wont be awful.
18:14:26 <bknudson> btw, can we have a 1.0 package depend on a < 1.0 package?
18:15:01 <bknudson> seems odd to have a stable lib depend on an unstable one
18:15:12 <morganfainberg> bknudson, i think we can.
18:15:24 <morganfainberg> bknudson, there is a lot of python that is not 1.0 and is used.
18:15:46 <morganfainberg> bknudson, we could release a 0.9 of middleware i guess and then make the next release of ksc 1.0? :P
18:15:47 <dolphm> bknudson: what's the < 1.0 package?
18:15:52 <bknudson> keystoneclient
18:15:54 <morganfainberg> dolphm, keystoneclient
18:16:31 <dolphm> i don't think it matters too much - we control both versioning schemes and know exactly how stable each are
18:16:44 <morganfainberg> bknudson, iso8601 is 0.1.9, pbr is < 1.0, prettytable is < 1.0, netaddr is < 1.0
18:16:49 <morganfainberg> i think we should be fine
18:17:00 <bknudson> ok, works for me
18:17:13 <bknudson> so keystonemiddleware is just waiting for the devstack change
18:17:18 <morganfainberg> yep
18:17:41 <morganfainberg> and then we can do a release [no blockers unless some change to the code is needed]
18:17:41 <bknudson> any reviews in progress that we should have in?
18:17:43 * topol morganfainberg digging up the concrete example!
18:18:07 <morganfainberg> bknudson, i think we said 1.0.0 will be a straight cut over
18:18:19 <bknudson> I thought there were some docs
18:18:36 <morganfainberg> we got readme and contributing added
18:18:37 <morganfainberg> already merged
18:19:08 <bknudson> ok
18:19:14 <jamielennox> morganfainberg: i was thinking (and been lazy about it) that we should take the opportunity to make everything in auth_token private
18:19:28 <jamielennox> everything but the class defenition
18:19:44 <morganfainberg> dolphm, want to keep as is or make that changeover before release?
18:19:53 <morganfainberg> dolphm, should be an easy/transparent change
18:20:06 <jamielennox> it'll make porting patches a bit harder between the two, but we've always had the problem that people want to override it where they shouldn't
18:20:35 <morganfainberg> jamielennox, i'm ok with that, but i'll defer to dolphm
18:20:40 <dolphm> i'm leaning towards that being a 1.1 thing :-/
18:20:50 <dstanek> jamielennox: will that actually stop them?
18:20:53 <bknudson> maybe that it's in keystonemiddleware now rather than in an API will convince people that they shouldn't override things
18:21:05 <morganfainberg> bknudson, ++
18:21:11 <topol> jamielennox, is that code someone would want to override?
18:21:14 <jamielennox> dstanek: probably not but it's a clear sign that if they do and we change it then it's there own fault
18:21:28 <bknudson> there -> their
18:21:34 <jamielennox> dolphm: sure, but if we're calling something 1.0 we are declaring it stable and non-changing api - this wouldn't be
18:21:39 <topol> dstanek, it may not stop them but it gives us coverage when they bitch
18:21:54 <topol> dstanek, been to that rodeo before
18:22:01 <jamielennox> topol: i always thought no, but there's always someone doing odd things - it has come up before
18:22:05 <morganfainberg> jamielennox, we have said in the past middleware internals are internal. we just ddin't do that before
18:22:14 <dolphm> jamielennox: propose the patch, and let's talk in code review?
18:22:14 <morganfainberg> prefix with _ that is
18:22:47 <jamielennox> will do
18:22:52 <topol> jamielennox, I agree.  not having the prefix means someone can do a lot of overrides and then when we change the API, their whole world breaks and they are angry
18:24:05 <morganfainberg> ok quick second topic, non-persistent tokens. wanted input from folks on this.
18:24:11 <morganfainberg> https://review.openstack.org/#/c/103416/ I proposed making [token]/driver [token]/persistence_driver
18:24:35 <morganfainberg> this is the start of a long chain that will deprecate token_api, merge most of that functionality into the token_provider_api
18:24:49 <morganfainberg> token_api will be kept around for a cycle (like we did with the proxy for assignment from identity)
18:25:08 <morganfainberg> public Rest APIs are not affected by this, and already reference the token_provider_api
18:25:38 <morganfainberg> any thoughts / concerns / "don't you dare, I have an affair with the token_api and can't let it go" ?
18:26:08 <dolphm> morganfainberg: i don't like the inconsistency with other 'driver' options :(
18:26:11 <morganfainberg> this all driving towards making persistence of tokens through as minimal an interface as possible, so we can drop it easil.
18:26:12 * topol I broke up with token_api months ago\
18:26:47 <morganfainberg> dolphm, i could move it to [token_persistence]/driver
18:26:49 <morganfainberg> dolphm, instead
18:27:03 <dolphm> morganfainberg: all driver's are 'persistence' drivers, right?
18:27:09 <dolphm> drivers*
18:27:44 <morganfainberg> dolphm, i want to say no, but it was the exception to the rule and i don't remember which it is :P
18:27:51 <morganfainberg> dolphm, so, yeah i need to agree, they are.
18:28:51 <jamielennox> will non-persistant tokens need a driver? all will it be indicated by driver=None
18:28:57 <jamielennox> s/all/or
18:29:12 <morganfainberg> jamielennox, ideally that would be the way you do it. UUID would override that choice.
18:29:47 <morganfainberg> or i could just make that logic really part of the provider
18:30:05 <morganfainberg> only affects providers that implement persistence
18:30:07 <bknudson> so provider=pki persistence=None ?
18:30:21 <morganfainberg> oh wait. no, revoke by id implies need for persistence
18:30:45 <bknudson> why does revoke by id imply persistence?
18:30:48 <morganfainberg> there is a matrix of "needs / doesn't need" persistence. and if it needs persistence, it is configurable
18:30:58 <bknudson> extract the issued time from the token
18:31:05 <morganfainberg> bknudson, i want to revoke all tokens for user X, how do you know the IDs of that
18:31:22 <morganfainberg> bknudson, you need to search through the token persistence driver to find all the token ids belonging to user X
18:31:31 <bknudson> oh, you're saying if you use revocation list you need persistent tokens
18:31:35 <morganfainberg> bknudson, yep
18:31:39 <bknudson> makes sense
18:31:51 <bknudson> but if you're using revocation events then don't need persistent tokens
18:32:05 <morganfainberg> bknudson, and "revoke_by_id" is the option [probably should be renamed to "use_revocation_list")
18:32:10 <morganfainberg> bknudson, using revocation events exclusively
18:32:21 <morganfainberg> bknudson, some environments may need both (mix of middleware?)
18:33:32 <bknudson> this is going to require a novel in the sample config.
18:33:36 <dolphm> disable the token (persistence) driver should implicitly disable revocation list, right?
18:33:48 <morganfainberg> dolphm, unless you're using UUID tokens
18:34:02 <dolphm> morganfainberg: then you can't disable the persistence driver anyway
18:34:06 <morganfainberg> dolphm, ++
18:34:17 <dolphm> morganfainberg: that should be a fatal exception on startup
18:34:22 <morganfainberg> dolphm, yes
18:34:27 <boris-42> morganfainberg dolphm btw guys I addressed comment about plugins for rally in keystone
18:34:41 <boris-42> morganfainberg dolphm  https://review.openstack.org/#/c/98836/
18:34:46 <boris-42> seems like mergable=)
18:34:48 <morganfainberg> dolphm, so yes, we could disable revocation_list based on disabling the persistence
18:35:14 <morganfainberg> might be the easiest way.
18:35:16 <topol> morganfainberg, definitely will need some good docs to keep this all straight
18:35:21 <morganfainberg> topol, yes we will
18:35:54 <bknudson> this is an opportunity for us to develop a gui
18:36:07 <morganfainberg> bknudson, can it be written in java?
18:36:13 <dstanek> morganfainberg: go
18:36:24 <bknudson> morganfainberg: that's the language we know!
18:36:47 <topol> morganfainberg, Jquery and AngularJS?
18:37:05 <morganfainberg> so does anyone have issues with deprecating token_api internal interface?
18:37:16 <topol> who is gonna do the accesibility review for the GUI???
18:37:20 <morganfainberg> regardless of the other mechanisms we bring along (persistence vs uuid vs revocation_list)
18:37:42 <bknudson> morganfainberg: what's the problem with it?
18:38:07 <morganfainberg> bknudson, trying to make it so anything that "stores" or "accesses" tokens from the persistence engine goes through one interface
18:38:18 <morganfainberg> and the provider_api duplicates a lot of functionality
18:38:32 * topol topol refuses to build a java GUI ever again :-)
18:38:53 <morganfainberg> i'd rather the provider_api be the interface for all of this stuff since it's providing the tokens, regardless of if we persist tokens to something or not
18:39:17 <dolphm> morganfainberg: are we still supporting gui interfaces using visual basic to track tokens?
18:39:33 <bknudson> I'm surprised that gyee hasn't made a comment since he wrote it
18:39:45 <bknudson> although he's probably painting himself red white and blue
18:39:53 <morganfainberg> dolphm, only because two people were typing on the keyboard at once to build that app
18:40:36 <morganfainberg> bknudson, we'd be keeping the token_provider_api, and just making token_api disappear in K (send a nice fat warning "HEY DONT USE THIS YOU HAVE ANOTHER OPTION") in J
18:40:47 <dolphm> morganfainberg: well then as long as the token provider API supports four hands on the keyboard at once i'm good
18:40:59 <raildo> morganfainberg: I was discussing at the meeting of hierarchical multitenancy about inherited roles, and we have two questions, this is a good moment to talk about that or i talk with you later?
18:41:05 <morganfainberg> dolphm, sold
18:41:06 <topol> thats a big keyboard
18:41:17 <morganfainberg> ok i'm out of things to talk about :)
18:41:19 <dolphm> topol: at least with a 10-kay
18:41:44 <henrynash> raildo: when is this meeting, btw, I’d like to attend
18:41:50 <topol> #topic, restaurant options for the Hackathon?
18:42:22 <morganfainberg> topol, # some taco stand that brad will be told to meet us at after 9pm? *duck*
18:42:24 <raildo> henrynash: friday, 16:00 UTC
18:42:41 <henrynash> raildo: thx
18:42:44 <topol> morganfainberg. I fixed that. Im buying drinks first night
18:42:46 <morganfainberg> topol, (don't hurt me, and still buy the first round of drinks0
18:43:02 <lbragstad> What-a-burger? I hear that it's magical
18:43:09 <morganfainberg> raildo, we are in open discussion here, if this is somehting for the wider eystone audience / meeting, this is a good time to chat
18:43:19 <morganfainberg> raildo, if not we can chat post meeting (and post lunch for me)
18:44:24 <jamielennox> i would love people to take a look at the series: https://review.openstack.org/#/c/95015
18:44:30 <raildo> morganfainberg:  I was going to lunch now as well, I'll talk to you in #openstack-keystone later, ok?
18:44:31 <henrynash> morganfainberg, dstanek, ayoung: sorry to stalk, but if one of you could (hopefully_ give the final +2 to https://review.openstack.org/#/c/102430
18:44:39 <morganfainberg> raildo, sounds great
18:44:42 <jamielennox> they are what I most need for using keystoneclient with other clients
18:45:15 <jamielennox> just had to update the first for a few bknudson comments - but they were doc fixups, and the code itself has been unchnaged for a while
18:45:17 <bknudson> also, somewhat related to jamielennox reviews -- I wrote up a spec for nova to use use v3
18:45:20 <henrynash> morganfainberg, dstanek, ayoung: it’s teh 2nd of the 3 multi-backend uuids pacthes, just rebasing the 3rd now
18:45:40 <dstanek> henrynash: shoudl there be some foreign key relationships in that table? or are they left our on purpose?
18:45:55 <bknudson> https://review.openstack.org/#/c/103617/
18:45:56 <jamielennox> once we have that chain in, a release would be useful
18:46:05 <dolphm> jamielennox: i don't see how that patch has anything to do with the blueprint?
18:46:05 <morganfainberg> henrynash, i am withholding a +2 on the one i did the sql work in
18:46:11 <morganfainberg> henrynash, otherwise i will review others
18:46:32 <henrynash> dstanek: so right now the mapping table is in identity…so can’t fk to assignment
18:46:40 <bknudson> #link nova spec for use identity v3: https://review.openstack.org/#/c/103617/
18:46:40 <dolphm> jamielennox: there's also an open bug that sounds a lot like the bp description... have a link to that?
18:46:48 <dolphm> jamielennox: it was sort of recent
18:46:51 <henrynash> morganfainberg: ?
18:46:59 <jamielennox> dolphm: a standard way of loading session and auth plugins from conf
18:47:19 <jamielennox> dolphm: i don't know the one off the top of my head
18:47:21 <morganfainberg> henrynash, i contributed code to https://review.openstack.org/#/c/102430/4 so i am not +2ing it :)
18:47:24 <bknudson> jamielennox: so auth_token would change to have those config options?
18:47:35 <morganfainberg> henrynash subsequent patches i will review.
18:47:38 <dolphm> jamielennox: that ^ doesn't have anything to do with the bp: "so that we get the same config options everywhere. This also helps developers create the objects and means that config and CLI options will be automatically updated by changes in keystoneclient."
18:47:39 <jamielennox> bknudson: no, the options match auth_token
18:47:42 <dstanek> henrynash: ah, makes sense
18:47:44 <henrynash> morganfainberg: ah, sorry got ya!
18:48:05 <bknudson> jamielennox: and for example nova can use those options when it switches to use session for neutronclient?
18:48:50 <jamielennox> dolphm: the patch is about registering CONF options required for the session and being able to load one from those optoins
18:49:20 <jamielennox> dolphm: so same config options, and if we add things to register_ in ksc then we can use them in load_from_ without having to change every consumer
18:49:37 <dstanek> henrynash: what line 26 doing https://review.openstack.org/#/c/102430/9/keystone/common/sql/migrate_repo/versions/051_add_id_mapping.py ?
18:49:37 <jamielennox> bknudson: that's the intention
18:49:45 <bknudson> jamielennox: but the config setup doesn't have auth plugin stuff yet?
18:49:55 <jamielennox> bknudson: they are the reviews after that
18:50:03 <jamielennox> they are a bit more difficult
18:50:08 <bknudson> ok
18:50:14 <dolphm> jamielennox: this seems to be completely missing the pain point that we're seeing in every other project using keystoneclient
18:50:21 <henrynash> dtsanek: ahh…damn…left over from when I mistakingly DID haev a FK in there!
18:50:41 <henrynash> dstanek: it’s a fair cop, guv
18:50:43 <dolphm> jamielennox: so i don't understand where this solution is coming from - where is the problem that it is solving?
18:51:12 <dstanek> henrynash: i only got 3 files in on the latest, but i can finish up after this meeting
18:51:19 <jamielennox> dolphm: so every service ends up with things like cacerts and usernames and passwords scattered through there config files
18:51:30 <bknudson> there -> their
18:51:32 <henrynash> dtsaneK; ok, great….I’ll wait for those, then re-patch as required
18:52:05 <morganfainberg> bknudson, hehe
18:52:05 <jamielennox> dolphm: i want a standard mechanism that says create a session object from these config options and have all the config options named the same across all the projects
18:52:15 <jamielennox> dolphm: eg heat uses ca_cert not cacert
18:52:17 <henrynash> dstanek: thx
18:52:26 <jamielennox> dolphm: this is more important when we get to auth_plugins
18:52:57 <jamielennox> dolphm: we need a way to load any auth plugin (not just username/password as in current configs) and create a client based on that
18:53:22 <jamielennox> and we can't expect the other clients to figure out how to do that
18:53:23 <bknudson> there's a lot of auth options that aren't going to be useful in a config file
18:53:38 <jamielennox> so the procedure would be
18:54:00 <jamielennox> auth = keystoneclient.auth.conf.load_from_conf(CONF, group)
18:54:16 <jamielennox> session = keystoneclient.session.Session.load_from_conf(CONF, group, auth=auth)
18:54:32 <jamielennox> client = keystoneclient.client.Client(session=session)
18:55:27 <bknudson> or client = neutronclient.client.SessionClient(session=session)
18:55:30 <dolphm> jamielennox: right, what you're doing is forward-looking, but the problem statement sounds like this- https://bugs.launchpad.net/python-keystoneclient/+bug/1332337
18:55:32 <uvirtbot> Launchpad bug 1332337 in python-keystoneclient "python-keystoneclient not providing shell parameters" [Wishlist,In progress]
18:55:48 <jamielennox> bknudson: right
18:56:30 <jamielennox> so he's looking at CLI
18:56:55 <jamielennox> that'd be: https://review.openstack.org/#/c/95678/ and https://review.openstack.org/#/c/95679/
18:58:13 <jamielennox> same concepts though
18:59:08 <dolphm> jamielennox: this looks like the patch i was expecting: https://review.openstack.org/#/c/95680/2/keystoneclient/shell.py
18:59:11 <dolphm> now i get it!
18:59:30 <bknudson> that bug says in progress but I don't see a review
19:00:25 <marekd> jamielennox: BTW. for the saml auth plugin i'd need to be able to pick another plugin (for IdP authN) load it and pass some params there. Of course params would differ per idp-authN plugin. Do you think we should make it somehow hierarchic or maybe try to squeeze parameters in one group/section, for both plugins (Unscoped token plugin and idp-auth plugin)
19:00:27 <dolphm> bknudson: re-assigned :-/ wish i had known about jamie's work sooner
19:00:33 <dolphm> (time)
19:01:24 <dolphm> #endmeeting