18:03:29 <stevemar_> #startmeeting keystone
18:03:31 <openstack> Meeting started Tue Oct 20 18:03:29 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:34 <openstack> The meeting name has been set to 'keystone'
18:03:36 <henrynash> (slinks in late)
18:03:40 <stevemar_> agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:03:45 <stevemar_> henrynash: hey! o/
18:04:03 <stevemar_> #topic What's up with keystoneauth-integration feature branch in python-keystoneclient?
18:04:10 <stevemar_> bknudson: all you bud
18:04:24 <bknudson> what's up with keystoneauth-integration?
18:04:29 <dolphm> lol
18:04:35 <bknudson> there's reviews posted to it.
18:04:36 <stevemar_> morgan: jamielennox?
18:05:03 <jamielennox> it was supposed to be removed in favour of a ksc v2 branch
18:05:15 <jamielennox> the powers that be said we shouldn't do a v2 branch and do it all on master
18:05:21 <bknudson> ok, so we're dropping it?
18:05:31 <bknudson> I think we should have a 2.0 branch
18:05:38 <jamielennox> i do too
18:05:58 <bknudson> otherwise we might wind up releasing half a 2.0 or not being able to release.
18:05:59 <stevemar_> a 2.0.0 branch makes sense to me
18:06:09 <jamielennox> yea, dropping it. it was for when ksc 1 was going to have a dependency on ksa. we're not doing that anymore
18:06:19 <stevemar_> we can remove a whole bunch of crap from there and iterate faster
18:06:29 <dolphm> #link https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:feature/keystoneauth_integration,n,z
18:06:52 <jamielennox> well apparently the reason was that we should do it in master and that way the gate would enforce everything worked
18:07:06 <jamielennox> which just doesn't work because no-one else will pick it up until we put it on pypi
18:07:39 <bknudson> as far as I can tell there's no way to tell if we're breaking stuff when we remove things
18:07:49 <stevemar_> so how can we, right ^
18:08:05 <bknudson> otherwise the gate wouldn't break all the time when releases are done
18:08:07 <dolphm> bknudson: things = branches?
18:08:26 <bknudson> dolphm: in this case it's things = functionality in keystoneclient
18:08:34 <stevemar_> there are surprisingly few open patches in KSC
18:08:38 <jamielennox> so i think this is going to be a really difficult transition however we do it
18:08:57 <jamielennox> we can't bump reqs project by project
18:09:27 <jamielennox> we can't test against the git repo without adding new jobs to each project we're working on
18:09:55 <bknudson> we know keystone will break since it's using deprecated ksc function.
18:10:16 <bknudson> anyways, this has gotten a bit off topic. I was just wondering about keystoneauth-integration and I got my answer.
18:10:17 <jamielennox> lol - and even keystone is doing it wrong :)
18:10:39 <stevemar_> bknudson: there isn't much on the agenda, we can discuss this if it's beneficial
18:10:43 <bknudson> I'm going to -2 everything in there.
18:11:36 <jamielennox> there's only i think one patch which was really proposed against the integration branch (off the top of my head) that i feel bad about because we told them to propose it there rather than master
18:11:49 <jamielennox> i think it was doug-fish ?
18:12:02 <bknudson> and then I guess work with infra to get rid of the branch
18:12:03 <stevemar_> jamielennox: probably
18:12:21 <stevemar_> yep
18:12:24 <doug-fish> yeah could be. I'll get over it for sure.
18:12:40 <bknudson> are the changes proposed to get ksc using ksa?
18:13:20 <stevemar_> bknudson: nope; https://review.openstack.org/#/q/project:openstack/python-keystoneclient+status:open,n,z
18:13:26 <jamielennox> bknudson: there were a few of those merged, but if we're going down the 2.0 path it's going to be easier to rip and replace than try and do a compatible dependency
18:13:57 <bknudson> I think we need to do a compatible dependency otherwise there's no way to upgrade.
18:14:53 <jamielennox> so the big change with 2.0 will obviously be removing everything from Client.__init__ in favour or session/adapter
18:14:57 <roxanaghe_> what about this one: https://review.openstack.org/#/c/215261/ I was told to put it on that branch because it was too risky for master..?
18:15:22 <bknudson> roxanaghe_: that will go in the 2.0 branch if we make one
18:15:43 <roxanaghe_> bknudson, ok..
18:15:43 <jamielennox> beyond that there are a couple of changes, but they're to like AccessInfo.create and stuff that i doubt will affect most people and it's an easy swap to the new function
18:16:16 <jamielennox> roxanaghe_: ah, that's the one i meant that we pushed to the integration branch
18:16:21 <morgan> bknudson: removing the branch is easy
18:16:30 <morgan> bknudson: just have stevemar_ ask the release team / infra.
18:16:52 <stevemar_> morgan: cool, i'll ask them after the meeting
18:17:05 <morgan> bknudson: and -2 isn't needed on anything in that branch, it should all go away when the branch is deleted
18:17:23 <jamielennox> roxanaghe_: sorry about that, but it will happen in v2
18:17:26 <bknudson> morgan: it shouldn't be needed but I keep seeing people reviewing changes in there.
18:18:13 <roxanaghe_> jamielennox: no worries, I can submit that again when we have a new branch
18:18:15 <stevemar_> bknudson: hopefully we can have it removed quickly
18:18:47 <stevemar_> looks like we still have some work to do in this area
18:18:59 <jamielennox> stevemar_: so maybe we need a new decision on the v2 branch whilst you're dealing with that
18:19:16 <stevemar_> jamielennox: a v2 branch sounds like the right move to me
18:19:18 <bknudson> my vote is for a 2.0 branch
18:19:24 <shaleh> ++
18:19:32 <stevemar_> i want to do a rip and replace, but i know it won't fly
18:19:39 <jamielennox> i mean either we get a v2 branch or we have to fork a 1.x branch for compatibility - either way is esentially the same thing
18:19:48 <morgan> we could do a ksc2 project
18:19:56 <morgan> in pypi / elsewhere
18:19:56 <bknudson> then propose all the deprecated function removals you want to 2.0 branch
18:20:23 <morgan> and do a "Freeze" on current ksc
18:20:48 <bknudson> Other projects aren't going to have an easy time switching from ksc1 to ksc2 if we're breaking everything.
18:21:04 <shaleh> was a reasonable argument made against the 2.0 branch?
18:21:06 <morgan> bknudson: we're going to have a hard time removing anything from ksc1
18:21:16 <stevemar_> morgan: python-keystoneclient2 ?
18:21:20 <bknudson> this is why semver says you only remove deprecated function
18:21:24 <jamielennox> bknudson: the problem is going to be mainly all the people that are using exactly what we want to deprecate
18:21:29 <jamielennox> and remove
18:21:36 <morgan> bknudson: and we know how well we've done with semver in openstack
18:21:37 <dolphm> introducing backwards incompatible changes will never foster adoption
18:21:52 <jamielennox> shaleh: i think the point was that if we did it in master then the gate would enforce we only did things that other projects could cope with
18:21:54 <morgan> stevemar_: i'd drop "python" from it
18:21:54 <bknudson> it's all marked as deprecated now. The openstack policy is 6 months to move off.
18:22:18 <jamielennox> shaleh: which is not something i buy
18:22:34 <morgan> except the client libs are used outside of openstack and will likely break people and make the end users very cranky
18:22:47 <shaleh> jamielennox: the gate runs the project's unit tests and what else?
18:23:01 <jamielennox> right, assuming that we are going to catch every use of keystoneclient is ridiculous
18:23:06 <bknudson> we can continue to support the 1.0 branch and do releases, just no new function.
18:23:23 <morgan> bknudson: the issue is the same thing we hit with upstream libs
18:23:36 <morgan> bknudson: they change something and release the "same" project and it breaks everything
18:23:36 <jamielennox> shaleh: it runs functional test as well, but for everything except the unit test it uses the library version released on pypi - so it's not going to test this stuff anyway
18:23:38 <morgan> anyway
18:23:40 <bknudson> every user will have to cap <2.0
18:23:46 <morgan> i'm just playing devils advocate
18:23:51 <morgan> i don't really care how we get to 2.0
18:24:15 <morgan> branch, new project, etc
18:24:25 <stevemar_> if the choice is between a new project (keystoneclient2) or a branch, i think i'd prefer a new project
18:24:36 <morgan> the only reason I think a new project *may* make sense is the split of middleware and session
18:24:41 <morgan> if it was strictly crud interfaces
18:24:43 <bknudson> the branch is optional, it just makes it easier to do the reviews
18:24:49 <morgan> i'd say I don't care as much
18:25:02 <morgan> and a new version of 2.0 would be a lot less impactful
18:25:02 <bknudson> we could put all of the removals in 1 patch, too.
18:25:14 <stevemar_> bknudson: jamie already did that
18:25:29 <jamielennox> ideally i'd prefer not to do a new project. we're not the first project to try and remove stuff from client, but we are depended upon by a lot of people
18:26:16 <stevemar_> so we'll just have a bunch of folks using <2.0.0
18:26:18 <morgan> jamielennox: and we're def. unwinding that issue (it's still all auth related)
18:26:19 <dolphm> why do we need a v2 client, exactly?
18:26:26 <ayoung> I think the only thi8ng critical to remove from client is the CLI functionality.  Programmatic changes are easier to shim
18:26:55 <morgan> ayoung: auth/session and CLi - the auth stuff is the reason things are so interdependant
18:26:57 <jamielennox> bknudson: i did some testing with this a while ago https://github.com/jamielennox/python-keystoneclient/tree/v2 is where i was pushing patches
18:27:06 <bknudson> dolphm: there's a lot of function that's deprecated in ksc and it would be nice to get rid of it.
18:27:19 <bknudson> since it's technical debt now
18:27:39 <dolphm> so delete it all at once and version bump - why worry about a new branch / new repo to do that?
18:27:59 <jamielennox> there's like a couple of layers of maintaining compatibility because everyone would use ksc for auth then reach in and grab tokens and other info
18:28:03 <morgan> dolphm: because the ripple effect breaking everything that didn't properly cap <2.0
18:28:11 <bknudson> dolphm: it's just a lot of code so it would be easier to review in smaller patches.
18:28:30 <ayoung> morgan, I think there is a distinction worth making.  With package dependencies, yeah, we would like them to move ahed, but the general workflow, what is avaialble, is the same (if duplicated) where as with CLI, we are talking different workflow and scripting.  It is, I think the CLI usage that is holding us back, far more than anything programmatic
18:28:31 <morgan> dolphm: and ^ what bknudson said
18:28:35 <dolphm> but we don't have those patches to review today anyone?
18:28:41 <dolphm> anyway*
18:28:55 <morgan> ayoung: I'd argue that auth is as big a hold back as the CLI in this case
18:29:02 <jamielennox> dolphm:  i'll essentially drop https://github.com/jamielennox/python-keystoneclient/tree/v2 into review
18:29:20 <ayoung> morgan, with KSC we can still move them to the 3.0 AOPI.  CLI does not allow that
18:29:34 <ayoung> but we should p[lan it all, so I'm not really arguing against
18:29:38 <ayoung> just prioritizing
18:29:42 <dolphm> jamielennox: i don't know what the diff there is
18:30:06 <stevemar_> dolphm: https://review.openstack.org/#/c/221596/
18:30:09 <jamielennox> dolphm: the last 8 patches of history starting with "remove cli"
18:30:16 <shaleh> if a new version of ksc is released it will break everyone who has not already put an explicit <2.0 in their requirements, right?
18:30:18 <bknudson> we need to at least get keystone not using deprecated ksc stuff.
18:30:29 <morgan> shaleh: yes.
18:30:32 <bknudson> I assume auth_token is using deprecated stuff, too.
18:30:38 <morgan> bknudson: likely.
18:30:46 <morgan> bknudson: but that can be fixed with moving to ksa
18:30:52 <morgan> bknudson: and should be much easier
18:30:54 <dolphm> our we worried about breaking openstack projects with a 2.0 release, or third party projects?
18:31:02 <morgan> dolphm: both
18:31:05 <shaleh> 3rd party are a big deal here
18:31:06 <bknudson> sure, but somebody's got to do it.
18:31:38 <ayoung> what are we talking about removing exactly here?
18:31:43 <bknudson> shaleh: it won't break anyone unless they're using deprecated function.
18:31:51 <dolphm> solving openstack projects is easy. you're not going to avoid breaking third party projects any further if there's already proper deprecations and version bumps happening
18:32:16 <jamielennox> ayoung: the CLI, creating clients with username= etc, bunch of compatibility things like getting project_id from the ksc Client object
18:32:21 <morgan> bknudson: it should mostly be drop in on the auth_token front
18:32:21 <morgan> that is about as easy as the other client libs that just do auth
18:32:22 <morgan> mostly minimal a different import
18:32:44 <jamielennox> yea, auth_token is fine - and if not it's something we have control over
18:33:17 <jamielennox> hopefully i can finish this auth_token in front of keystone soon and we won't need like the cms options in ksc either
18:33:38 <morgan> jamielennox: we should just move cms to middleware anyway
18:33:48 <morgan> jamielennox: keystone already depends on ksm
18:33:58 <jamielennox> oh, then yes
18:34:05 <ayoung> KC never claimed to validate tokens.  If needs be, we can drop CMS.  Needs to stay available to middleware until PKI tokens are dropeed
18:35:40 <shaleh> looking at the changes, auth is a likely point of failure and it is a pretty straightforward change for the developer. This should be safe enough to release.
18:36:05 <shaleh> we could make an announcement or two, get it out there so people know it is coming.
18:36:08 <ayoung> So have we at a minimum deprecated everything we want to remove long enough ago such that we are within the letter of the law in removing?
18:37:12 <mordred> I would recommend getting people off of ksc completely before removing anything - letter of law notwithstanding
18:37:27 <jamielennox> mordred: how do we make that list
18:38:17 <mordred> jamielennox: http://hound.openstack.org/?q=keystoneclient&i=nope&files=&repos= is a good start
18:38:30 <mordred> although that's out of date because we haven't restarted hound since doing the renames
18:38:53 * dstanek is here now
18:39:08 <ayoung> mordred, my question still stands
18:39:14 <stevemar_> dstanek: o/
18:39:42 <ayoung> We need to get people moving.  We can say 'We'lgrant a repreive if you ask' but we are not going and changing every single project out ther
18:39:43 <ayoung> e
18:39:50 <mordred> ayoung: I do not know. of course, I'm more in favor of openstack never deprecating anyting ever again because it just moves the complexity to the end user
18:39:58 <mordred> so I might not be the right person to ask
18:40:03 <stevemar_> mordred: why am i just learning about http://hound.openstack.org/ now?
18:40:07 <ayoung> But, we can't even remove it if we did not deprecate it.
18:40:10 <mordred> stevemar_: it's not a live service yet
18:40:10 <jamielennox> wow, i thought our problem would be session, there's still a lot of instances of keystoneclient.auth_token
18:40:13 <jamielennox> stevemar_: me too
18:40:18 <marekd> and me
18:40:23 * mordred is going to start changing all of the openstack porjects
18:40:29 <mordred> has started with neutronclient
18:40:35 <mordred> is doing novaclient and glanceclient next
18:41:08 <shaleh> jamielennox: but this is all solvable with direct effort and quickly enough.
18:41:22 <mordred> because someone needs to do the work, and because I want them all to support keystone v3 and clouds.yaml sooner rather than later
18:41:34 <mordred> and I think getting them on to ksa is the quicketst way to do that
18:41:36 <shaleh> mordred: ++ for clouds.yaml
18:41:58 <jamielennox> shaleh: i mean the code will still work, it's a matter of finding it and getting people to fix it - and the deprecation warnings have necessarily done that
18:42:05 <mordred> once that's done, I'd argue that caring about the functionality in ksc is a thing that is less important
18:42:36 <jamielennox> i think the realistic path for M is to deprecate all the Session stuff in ksc in favour of KSA
18:42:46 <jamielennox> and spend the cycle moving everyone across to ksa
18:42:48 <ayoung> So...when did we deprecate this functionality?
18:42:58 <ayoung> Was it 1 year ago?
18:43:08 <mordred> jamielennox: ++
18:43:20 <jamielennox> ayoung: ksc.Session hasn't been because it's only been available since ksa release but it's just s/keystoneclient/keystoneauht there
18:43:20 <ayoung> jamielennox, ++  If things are not yet deprecated, first thing is to deprecate.
18:43:21 <bknudson> the keystone CLI was deprecated earlier than all the username, etc. parameters.
18:43:42 <ayoung> We can work on a punchlist of what needs to be fixed after we'
18:43:52 <ayoung> ve got the official path forward documented
18:44:11 <david8hu> a wiki page to keep track of things...
18:44:14 <shaleh> sounds like a reasonable plan of action
18:44:30 <jamielennox> right and we would need to document this and everything, i'd be impressed if we were even in a position where people would accept this this cycle
18:44:47 <mordred> jamielennox: which bit? the move to ksa? or the deprecation?
18:44:49 <stevemar_> we need to cut this in about 5 minutes
18:44:57 <jamielennox> mordred: removing all deprecated stuff from ksc
18:44:59 <shaleh> the changes are small, we could even propose the fixes if needed
18:45:03 <jamielennox> in favour of ksa
18:45:20 <mordred> jamielennox: I agree. I do not think that will fly this cycle
18:45:26 <mordred> jamielennox: I think deprecating this cycle will
18:45:32 <jamielennox> ype
18:45:36 <jamielennox> yep
18:45:36 <mordred> jamielennox: and getting projects moved to ksa this cycle will
18:46:03 <bknudson> sounds like we're saying spend the effort on migrating other projects to ksa rather than removing function
18:46:13 <bknudson> except for the keystone CLI?
18:46:31 <mordred> does osc support keystone v2 catalog?
18:46:37 <jamielennox> bknudson: it's hung around this long, we'd have to major version to drop it
18:46:39 <stevemar_> mordred: yeppers
18:46:53 <mordred> great. then I do not personally care if it goes away :)
18:46:57 <bknudson> might be handy to have an etherpad to track the work on other projects.
18:47:04 <mordred> bknudson: ++
18:47:08 <bknudson> or a cross-project spec?
18:47:39 <morgan> bknudson: maybe. might be useful, might also just be in the range of "file a bug"
18:47:59 <bknudson> y, cross-project spec seems like overkill especially since they don't seem to carry any weight.
18:47:59 <morgan> don't know if this is really a "spec" but more a "bug" and fix code. ksa isn't a huge departure from ksc session
18:48:25 <morgan> and everyone should be on ksc.session already
18:48:26 <ayoung> ok... anything else we need to discuss, or wait until next week?
18:48:35 <jamielennox> but ok, i'll do a big bug and tag projects as i find it
18:48:37 <morgan> ayoung: in Tokyo!
18:48:52 <samueldmq> morgan: ++ a bug worked well when we proposed everyone to use the graduated oslo.policy (https://bugs.launchpad.net/bugs/1458945)
18:48:52 <openstack> Launchpad bug 1458945 in OpenStack Compute (nova) "Use graduated oslo.policy instead of oslo-incubator code" [Undecided,In progress] - Assigned to Jeffrey Zhang (jeffrey4l)
18:48:58 <samueldmq> which included a ton of projects
18:49:02 <dstanek> i just wanted to thank everyone for bugday - i think it went rather well
18:49:19 <morgan> jamielennox: I'd say make sure to call it out as a relatively minor change in the bug
18:49:45 <bknudson> we should get some docs in ksc or ksa for how to make the change.
18:49:47 <morgan> jamielennox: so when the question of "why this isn't a spec" comes up we can point at the bug and say "we have already outlined the minimal impact"
18:49:56 <morgan> bknudson: I'd vote in ksa
18:50:34 <dstanek> for those of you that don't follow me on twitter: bit.ly/1MMuAqC
18:50:46 <stevemar_> #topic Office Hours (bugday)
18:50:53 <stevemar_> (sorry about the late topic change)
18:51:13 <dstanek> i jumped the gun :-)
18:51:18 <stevemar_> it's all good
18:51:22 <dstanek> you can see that we had a rather large spike in overall activity
18:51:30 <stevemar_> it was pretty successful
18:51:39 <stevemar_> #link http://dstanek.com/keystone-bugday/2015-10-16/index.html
18:51:56 <dstanek> at tokyo i want to talk with the people that participated and see what else we can do or what we can do differently
18:52:05 <stevemar_> lots of invalid and inprogress marks!
18:52:19 <stevemar_> dstanek: doing another one this friday?
18:52:20 <mordred> morgan: https://review.openstack.org/#/c/236712/ btw - re: cross-project specs. it's about occ, but it implies ksa
18:52:37 * morgan nods
18:52:38 <dstanek> the first graph shows 3 spikes. the first two are automation marking things as fix released
18:52:42 <dstanek> stevemar_: yes
18:52:47 <shaleh> as I mentioned on the list, a solid bug scrub/update is in oder
18:52:55 <dstanek> i'll update the etherpad after this meeting
18:52:58 <shaleh> it is confusing what the state of the bugs are
18:53:21 <shaleh> there are half finished conversations, claims of things being implemented in one release or another, etc.
18:53:22 <dstanek> shaleh: that is what we were doing on Friday and hope to do every Friday
18:54:04 <stevemar_> shaleh: yeah, that's the point, getting the bug list to something sensible
18:54:07 <shaleh> dstanek: excellent. I have gone bug trolling once or twice and stopped because I was having problems identifying actual work to do
18:54:17 <jamielennox> dstanek: i really like that plan, i'm not sure timezones will work out for me though
18:54:18 <morgan> shaleh: a couple times over the cycles I've done a massive bug reconsiliation/cleanup/closeout. this is waaaaay better to have a consistent friday event
18:54:28 <shaleh> morgan: ++
18:54:31 <morgan> jamielennox: just do it on your friday :)
18:54:49 <jamielennox> morgan: what if there's then nothing left for the other people? :p
18:54:53 <marekd> jamielennox: i think dstanek would like to cover all timezones and make ithat Friday last 24 or more hours :-)
18:55:02 <morgan> jamielennox: then you're clearly the winner!
18:55:03 <dstanek> jamielennox: technically it's Friday UTC so feel free to work on bugs during that time!
18:55:10 <dstanek> marekd: ++
18:55:14 <stevemar_> i can help with late evening thursday :)
18:55:26 <stevemar_> and catch some early friday morning folks
18:55:33 <gyee> I only celebrate new year on all timezones
18:55:49 <marekd> gyee: in your private jet
18:55:56 <shaleh> looking forward to joining the bug party in two weeks after the Summit.
18:55:59 <gyee> one bottle per timezone
18:57:13 <stevemar_> friday contributor meetup can partly be a bug squash day in tokyo :)
18:57:28 <lbragstad> ++ that's a good idea
18:57:29 <shaleh> BTW, talking about bugs. The definition of "triaged" is not matching my expectation. I am accustomed to that term meaning the bug has been investigated, verified, and assigned a priority/release candidate.
18:57:45 <stevemar_> shaleh: that's what it should be
18:58:00 <shaleh> the online doc says triaged has a patch on it
18:58:09 <shaleh> which means ignore triaged bugs
18:58:19 <bknudson> #link https://wiki.openstack.org/wiki/BugTriage
18:58:28 <stevemar_> one last topic
18:58:32 <stevemar_> #project liasons
18:58:37 <stevemar_> #topic project liasons
18:58:44 <stevemar_> if you don't know what they are: https://wiki.openstack.org/wiki/CrossProjectLiaisons
18:58:45 <stevemar_> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
18:58:56 <stevemar_> let me know if you want to me one, poke me on -keystone
18:58:59 <stevemar_> that's it!
18:59:09 <stevemar_> last few seconds
18:59:14 <shaleh> "If the bug contains the solution, or a patch, set the bug status to Triaged"
18:59:15 <bknudson> and if someone else wants to be oslo liaison then pony up.
18:59:31 <stevemar_> bknudson: it's a turf war now
18:59:39 <stevemar_> #endmeeting