18:00:35 <morganfainberg> #startmeeting Keystone
18:00:36 <openstack> Meeting started Tue Feb 10 18:00:35 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:42 <openstack> The meeting name has been set to 'keystone'
18:00:49 <morganfainberg> So some quick house keeping and we'll get into the meeting
18:00:55 <morganfainberg> 1) Please review code.
18:01:04 <topol> o/
18:01:47 <morganfainberg> we've been slow on getting code landed due to limited feedback on open reviews, with exception of stevemar  and bknudson (and topol on -specs repo), we've all been somewhat guilty of letting things slide (myself included)
18:01:59 <joesavak> \o
18:02:08 <morganfainberg> so great job stevemar, bknudson, and topol, but you shouldn't need to carry all the reviews.
18:02:23 <ayoung> I've been slogging through access info....years of cruft....
18:02:29 <morganfainberg> ayoung, yep i know
18:02:34 <dstanek> i've been awful ...
18:02:47 <morganfainberg> but if you work on that other reviewers should be easily covering the gap
18:03:10 <morganfainberg> ayoung, taking a break to work on a major initiative like accessinfo shouldn't impact us that much, but everyone has been off elsewhere
18:03:23 <morganfainberg> ayoung, so it's def. not you specifically
18:03:37 <ayoung> We hates...oh we hates it precious...no no we loves it.
18:03:40 <morganfainberg> part of it is that the core team is small and we've been very busy everywhere.
18:04:02 <morganfainberg> so, in that light i've proposed marekd as a new addition to the core team: http://lists.openstack.org/pipermail/openstack-dev/2015-February/056478.html
18:04:04 <gyee> precious
18:04:04 <morganfainberg> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056478.html
18:04:30 <gyee> not sure about that Friday the 13th date though
18:04:40 <morganfainberg> gyee, shh, it's a lucky day
18:05:02 <gyee> for those of us into lunar calendar, 13 is a lucky number!
18:05:03 <morganfainberg> his added +2/-2 capability will help smooth things out as well even as we see an uptick from other core reviewers.
18:05:43 <morganfainberg> and...
18:05:49 <morganfainberg> hm. there was one more housekeeping thign
18:05:50 <rodrigods> ++
18:06:18 <ayoung> marekd, marekd ... he'll go down in history!!!!
18:06:29 * ayoung has a little bit of cabin fever
18:06:38 <morganfainberg> Reminder March 5th is Feature proposal freeze
18:06:39 <marekd> ayoung: by creating the biggest black hole with help of OpenStack
18:06:42 <marekd> :-)
18:07:05 <ayoung> You fool!  You will DESTROY US ALL!
18:07:19 <rodrigods> lol
18:07:33 <morganfainberg> meaning, if the code is not ready to gate by march 5th, it isn't landing in Kilo w/o an exception on the mailing list (probably will include release manager ttx on if we'll accept it)
18:07:34 <marekd> morganfainberg: anyway, thanks for that opportunity, I will do my best go help you.
18:07:41 <marekd> s/go/to/
18:07:49 <morganfainberg> ok
18:07:53 <morganfainberg> on to the main agenda
18:07:55 <morganfainberg> #topic Allow disabling of SQL extra attribute storage
18:07:59 <morganfainberg> henrynash o/
18:08:10 <henrynash> hmm…that was from kast week!
18:08:14 <henrynash> last week, even
18:08:16 <morganfainberg> oh
18:08:18 <morganfainberg> hmm.
18:08:28 <morganfainberg> #undo
18:08:29 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x93ffa90>
18:08:34 <dolphm> rofl
18:08:35 <morganfainberg> was Email as a first class attribute also last week?
18:08:38 <gyee> marekd, your best? https://www.youtube.com/watch?v=w3UQwyKrTtI
18:08:38 <henrynash> yep
18:08:46 <morganfainberg> ok
18:08:47 <morganfainberg> Barbican backend for Keystone Credential API
18:08:49 <morganfainberg> ?
18:08:56 <bknudson> last week
18:08:58 <henrynash> not sure
18:09:06 <morganfainberg> hmm.
18:09:14 <morganfainberg> wow i really spaced on cleaning up the agenda
18:09:15 <morganfainberg> sorry
18:09:17 <henrynash> heh, we getting through this agenda really quick this week
18:09:26 <morganfainberg> ok so #topic Spec Proposal Deadline and Feature Proposal Freeze for L-Cycle
18:09:34 <morganfainberg> #topic Spec Proposal Deadline and Feature Proposal Freeze for L-Cycle
18:09:38 <henrynash> definitely not last week
18:09:48 <marekd> gyee: you are right :(
18:09:52 <morganfainberg> ok so since we just passed SPF (spec proposal freeze)
18:10:01 <morganfainberg> how does everyone feel about the timing of it
18:10:17 <morganfainberg> is m2 the right place for it, or should we be closer to m1 for the l-cycle
18:10:19 <ayoung> I propose that we no longer propse specs on a per release basis
18:10:37 <ayoung> -2 of a spec to hold it is dumb...lets just put everything in backlog until it is passed
18:10:48 <gyee> we have a name for L yeah? Love
18:10:50 <ayoung> then move to the slot where it is going to be implemented afterwards
18:11:00 <morganfainberg> ayoung, thats fine, but what would be the cut-off for moving things to a release
18:11:10 <ayoung> Spec freeze, of course
18:11:17 <morganfainberg> which is m2 a good time for it?
18:11:25 <morganfainberg> which was my original question ;)
18:11:27 <gyee> about spec and wip code together?
18:11:31 <henrynash> i think m2 is about right
18:11:37 <gyee> easier to comprehend
18:11:44 <morganfainberg> my only concern with m2 is we're very compressed in milestone 3
18:11:50 <ayoung> Meh..I think we are arbitrarily giving ourselves deadlines
18:11:52 <morganfainberg> and we have a lot of code to land
18:12:09 <rodrigods> m2 is close
18:12:13 <ayoung> we treat the specs as finished docs, and quibble over spellinggg
18:12:15 <rodrigods> what was the freeze used by nova? m1?
18:12:17 <morganfainberg> ayoung, as the person on the hook to manage what we're landing, i can say that is def. your view.
18:12:18 <dolphm> ayoung: the goal is to try and anticipate what is going to land, and help focus reviewers on a smaller subset of patches
18:12:39 <morganfainberg> ayoung, quibbling over the spelling should not be a -1 going forward, we're getting better about it but it's a slow move
18:12:55 <morganfainberg> rodrigods, yes it was m1 in nova afaik
18:13:10 <henrynash> morganfainberg: so when we had this discussion for K we said:
18:13:10 <morganfainberg> i think M1 is probably a better place for SPF
18:13:43 <morganfainberg> henrynash, we didn't start on specs till post RC for K - which did drive that decision as well. it's why i'm asking now so we can give lots of lead
18:13:47 <henrynash> morganfainberg: get specs in as soon as possible….m1 is best, m2 is latest….
18:13:53 <ayoung> morganfainberg, there are lots of artificialities here.  I'm not going to go off on a rant, but I think a spec should be submitted and approved in a single direcotry, and the milestone part should be accepting that code for a given release
18:14:01 <rodrigods> keeping M1 as SPF, we can focus first on have specs merged and than submit the code
18:14:06 <bknudson> we've got 27 approved specs for K... not sure what all has been completed already & what's left to complete -- http://specs.openstack.org/openstack/keystone-specs/
18:14:08 <rodrigods> midcycle would be a lot about coding
18:14:13 <bknudson> also, some blueprints don't have specs.
18:14:27 <ayoung> so, if a spec is not even approved by deadline, it certainly won't be allowed to be both approved and assigned to the deadline.
18:14:28 <henrynash> morganfainberg:……and if you leave it to m2 you rub this risk of it not getting ocde approved in time for m3….and that’s teh risk you run leaving the spec until m2....
18:14:31 <bknudson> so maybe should be looking at blueprints instead....
18:14:41 <morganfainberg> henrynash, exactly
18:14:53 <henrynash> morganfainberg: so I guess the question is, do we need to harden that advice....
18:14:58 <morganfainberg> so keep in mind this convo, i'll ask again in a couple weeks near FPF
18:15:08 <morganfainberg> and we'll make a call then for L-cycle
18:15:19 <morganfainberg> ayoung, and i'm fine with the change of how specs are proposed
18:15:23 <ayoung> I think what we have now is fine as far as the actual M2 freeze.  Keep the workflow stable and we'll work with it
18:15:27 <gyee> lets see how this cycle goes first
18:15:44 <morganfainberg> gyee, this is just seeding the idea to keep everything in mind. no decisions are being made today
18:16:02 <morganfainberg> ok thats it for my topic.
18:16:03 <ayoung> If anything, I think we could use some better guidelines on what goes in to aspec, and what is necessary for one to be approved.
18:16:15 <morganfainberg> #topic Open Discussion
18:16:18 <bknudson> 19 blueprints targeted to k-3
18:16:19 <ayoung> I'l like it to be something like this:
18:16:24 <bknudson> https://launchpad.net/keystone/+milestone/kilo-3
18:16:29 <ayoung> 1.  Idea is approved, but needs to be fleshed out;
18:16:42 <ayoung> 2.  Details are fleshed out and overall spec is approved
18:16:48 <gyee> x.509 authz wip coming shortly
18:16:49 <ayoung> 3.  Spec is assigned to a specific release
18:16:53 <morganfainberg> bknudson, and for the most part those have not been started or are in jepordy for not landing in k
18:16:57 <morganfainberg> bknudson, afaict
18:17:07 <morganfainberg> with a few exceptions
18:17:17 <dolphm> ayoung: aren't 1 and 2 just backlog, unless 3 is true?
18:17:25 <dolphm> and 2 is a pre-req for 3?
18:18:05 <ayoung> dolphm, Yes, but I think the backlog is far more important than we treat it.
18:18:33 <gyee> spec and wip code, wip code flush the details in the spec
18:18:42 <bknudson> I don't see what makes backlog important... what's important is getting features done and merged and working.
18:18:51 <gyee> agile :)
18:18:58 <ayoung> dolphm, you and I have  been doing thiws for 3+ years now, and we see just how fast the cycles pass.  I want to stop thinking in terms of "the next six months" and instead think in terms of "what should this look like"
18:19:00 <dolphm> ayoung: i don't know, i haven't experienced much value out of labeling something as "backlog" versus keeping it alive in gerrit until it's ready. maybe someone else has a different experience with backlog/?
18:19:15 <ayoung> next 6 months is just "those features that are ready go on the bus"
18:19:26 <morganfainberg> dolphm, i think the backlog makes sense from a "this is a good idea" and doesn't clog up gerrit
18:19:27 <lbragstad> backlog just seems like a way to get it off the main burner and worry about it later
18:19:36 <morganfainberg> if we have things that aren't going to land this cycle.
18:19:40 <bknudson> things change in 6 months so what we though was important 6 months ago maybe isn't anymore.
18:19:43 <morganfainberg> haivng a ton of -2s in gerrit is ugly
18:19:43 <dolphm> morganfainberg: gerrit solves that with -2's -> abandon
18:19:57 <dolphm> morganfainberg: abandon cleans those up nicely :)
18:20:01 <morganfainberg> dolphm, no the procedural -2 is crappy workflow
18:20:05 <morganfainberg> thats all.
18:20:06 <ayoung> Approved specs are really valuable in a org like ours where we have more and more people coming in to contribute, and the core needs to shift gears to supervisory mode
18:20:23 <ayoung> bknudson, then we can knock off a spec.
18:20:32 <morganfainberg> ayoung, i agree based upon internal HP stuff
18:20:45 <morganfainberg> having an approved list of things to work on helps them jump in
18:20:52 <gyee> ++
18:20:59 <morganfainberg> they want to work on things, but the "get a spec approved" is a big barrier
18:21:13 <morganfainberg> if we want some stuff in keystone, having a clear "this is approved to be worked on" is a benefit
18:21:21 <gyee> but we tend to argue alot over details in the spec
18:21:24 <morganfainberg> it drastically lowers the barrier to entry
18:21:25 <lbragstad> ++
18:21:28 <gyee> what's the right amount of details?
18:21:36 <morganfainberg> gyee, that is the important question.
18:22:38 <gyee> I am fine with presenting the "idea" in the spec and follow on with a wip review
18:22:44 <gyee> then API spec change if needed
18:22:47 <ayoung> ++
18:22:47 <bknudson> we already have a backlog: http://specs.openstack.org/openstack/keystone-specs/specs/backlog/README.html
18:23:09 <ayoung> so all -2ed specs we have righ now should be moved to backlog.
18:23:28 <ayoung> lets just start with that
18:23:45 <gyee> oh that's agile
18:24:42 <morganfainberg> bknudson, and we should use the backlog
18:25:24 <morganfainberg> anything else?
18:25:35 <samueldmq> Blueprints for No-Spec Requires Status
18:25:37 <morganfainberg> anything not on the agenda that we want to cover today?
18:25:38 <morganfainberg> sure
18:25:51 <morganfainberg> #topic BPs that don't need Specs
18:26:01 <samueldmq> ok .. .so I'm proposing Backends' Tests Restructuration
18:26:06 <morganfainberg> #link https://blueprints.launchpad.net/keystone/+spec/backends-tests-restructuration
18:26:18 <samueldmq> yes, basically split test classes
18:26:35 <morganfainberg> dstanek, o/ how does this work with the functional testing changes?
18:26:39 <samueldmq> considering the available backends (resource, assignment, etc)
18:26:44 <bknudson> I'm not a fan of the _ naming that we use in the tests... use / instead.
18:26:49 <bknudson> (i.e., split into subdirectories)
18:26:52 <samueldmq> #link https://github.com/openstack/keystone/blob/master/keystone/tests/test_backend.py
18:26:53 <morganfainberg> bknudson, ++
18:26:59 <dstanek> morganfainberg: i don't think it impacts it since they are not functional tests
18:27:01 <samueldmq> this one ^ has 5k + lines
18:27:05 <samueldmq> dstanek, ++
18:27:06 <dstanek> bknudson: ++
18:27:07 <morganfainberg> dstanek, ok just wanted to be sure :)
18:27:23 <henrynash> bknudson: yes, I though we might have backend/assignment/sql for example
18:27:28 <samueldmq> bknudson, I agree.. I also don't like to have everything in the same directory
18:27:38 <bknudson> do we want to get further on functional testing before we accept refactoring unit tests?
18:27:38 <morganfainberg> samueldmq, the only request i make is don't split everything in one patch ;) do it in reviewable bites
18:27:40 <samueldmq> bknudson, as we have the code structure
18:27:46 <dstanek> morganfainberg: samueldmq and i talked a little this morning about that topic
18:27:50 <bknudson> at least, move functional tests into functional and unit tests into unit/
18:27:51 <samueldmq> morganfainberg, sure!
18:28:08 <samueldmq> morganfainberg, I already started with test_v3_resource split
18:28:19 <bknudson> henrynash: backend/assignment/sql would be great!
18:28:19 <samueldmq> #link https://review.openstack.org/154080
18:28:39 <henrynash> samueldmq: …although that is one go!
18:28:45 <dstanek> this change does present the opportunity to move them into the unit directory
18:28:52 <morganfainberg> bknudson, i'll defer to you and dstanek on how you want to approach that (order of changing things)
18:29:02 <morganfainberg> but i think this bp doesn't need a spec
18:29:12 <morganfainberg> in fact... it feels like the poster child for not needing a spec
18:29:17 <henrynash> samueldmq: as now guardian of the <500 patch limit (hereby bestowed upon me by morganfainberg), let’s work together on this
18:29:19 <gyee> morganfainberg, don't split? have you look at this dependency chain? https://review.openstack.org/#/c/144703/
18:29:19 <ayoung> I like....we've wnated this for a \while.  jamie lennox proposed it early on
18:29:28 <samueldmq> henrynash, ++
18:29:44 <morganfainberg> so, yes we want this
18:29:44 <bknudson> I think dstanek (or someone) moving the existing tests into unit/ should be done first.
18:29:51 <bknudson> as part of functional testing.
18:29:57 <gyee> henrynash, sameldmq, s been doing dependency like everyday is tax day
18:29:59 <henrynash> bknudson: yes, kind of agree
18:30:04 <samueldmq> gyee, ++ :) I think I've splitted well there
18:30:13 <dstanek> bknudson: i can do some, but i don't want to put too many crappy tests in there
18:30:31 <bknudson> all of our tests now are unit tests, so they all go there.
18:30:34 <dstanek> i was making them better as i moved them over - but i can be less anal about that
18:30:41 <morganfainberg> bknudson, so lets have dstanek work with samueldmq on the getting things moved
18:30:45 <bknudson> dstanek: don't be anal!
18:30:55 <dstanek> bknudson: i would disagree and say we have we little actual unit tests
18:30:58 <morganfainberg> bknudson, as part of the functional test and this bp.
18:31:11 <samueldmq> bknudson, but they arent unit tests ... I'd argue they are integration, since they involve both manager + driver
18:31:16 <bknudson> dstanek: I agree that they're not unit tests but they don't use devstack.
18:31:24 <morganfainberg> before we devolve too far into ordering
18:31:32 <dstanek> bknudson: yes, that's true
18:31:35 <morganfainberg> do we want a spec for this? I say no a spec is not needed
18:31:42 <samueldmq> dstanek, bknudson they're integration tests
18:31:42 <morganfainberg> anyone view differently
18:32:02 <bknudson> well, I'd prefer to not use _ for the test names
18:32:10 <bknudson> so I don't like the blueprint as is.
18:32:22 <bknudson> _ for the test filenames.
18:32:23 <morganfainberg> bknudson, we can not approve the BP till it's ready
18:32:27 <samueldmq> bknudson, we can split and then restructure in directories (as this would involve more files than involved in this patch)
18:32:32 <morganfainberg> but does it need a spec.
18:32:38 <morganfainberg> i would say no.
18:32:51 <dstanek> i'd rather see something more like keystone.tests.unit.backends.identity
18:32:52 <morganfainberg> and i agree don't use _ for filenames
18:33:09 <bknudson> doesn't affect the api so I'm fine with no spec.
18:33:17 <morganfainberg> anyone really want a spec here?
18:33:19 <lbragstad> ++ it would be nice to have a tree structure for our tests
18:33:20 <gyee> no
18:33:22 <morganfainberg> going once
18:33:23 <dstanek> nope
18:33:24 <morganfainberg> twice...
18:33:24 <henrynash> no
18:33:26 <morganfainberg> no spec
18:33:26 <gyee> don't want spec either
18:33:33 <samueldmq> nice! thanks :)
18:33:45 <morganfainberg> but please work to make things better in the bp / clear before it is approved
18:34:11 <gyee> spec is needed whenever we mock around with any pubic interfacing stuff right?
18:34:23 <samueldmq> ok, will discuss in the channel to see what will be addressed in this bp (directories ?, etc) thanks
18:34:38 <bknudson> if there's a change to the identity or extension API then I'd expect a spec.
18:34:42 <morganfainberg> bknudson, ++
18:34:53 <topol> makes sense!
18:34:56 <dolphm> bknudson: for sure
18:34:57 <gyee> not just API, any public facing stuff
18:35:03 <bknudson> config options?
18:35:03 <gyee> including backend interfaces
18:35:07 <dolphm> gyee: ++ for anything that directly impacts users
18:35:08 <morganfainberg> bknudson, ideally yes
18:35:17 <dolphm> / deployers
18:35:37 <samueldmq> it depends, functional testing doesnt change identity apis, and we needed a spec :)
18:35:40 <bknudson> I don't think we even have a section in the spec to consider backend interfaces.
18:35:56 <gyee> bknudson, we need to
18:36:04 <gyee> vendor have their own backend drivers
18:36:05 <morganfainberg> samueldmq, that is a bit different, deployers might use the functional testing against a live cloud.
18:36:14 <morganfainberg> samueldmq, it's also drastically changing how we test
18:36:18 <bknudson> gyee: propose a spec!
18:36:27 <gyee> damn straight
18:36:33 <samueldmq> morganfainberg, ++
18:36:48 <bknudson> I think we wanted some initial docs for functional testing, too.
18:36:54 <morganfainberg> bknudson, ++ yes
18:36:55 <samueldmq> morganfainberg, yes, that should be an exception
18:36:56 <dstanek> samueldmq: that's also a pretty big effort - a spec is a great way to clarify things
18:37:21 <bknudson> also, just because we don't require a spec doesn't mean one can't be written up.
18:37:32 <morganfainberg> samueldmq, some of these cases we didn't ask for a spec, the proposer said "i'll do a spec" because it made it easier to explain things
18:37:37 <samueldmq> dstanek, I agree, was just pointing out that 'identity changes' requires a spec is true
18:37:48 <henrynash> bknudson: ++ in the past I’ve written one up to ensure everyone understood the impact
18:37:49 <samueldmq> dstanek, but not all specs are there because they change identity api
18:38:02 <bknudson> btw - proposed a spec to keystoneclient for deprecations -- https://review.openstack.org/#/c/153881/
18:38:07 <samueldmq> morganfainberg, hmm .. ok makes sense
18:38:59 <gyee> bknudson, good one!
18:39:09 <bknudson> a spec for https://blueprints.launchpad.net/keystone/+spec/backends-tests-restructuration would be nice, but I'm fine with not requiring one.
18:40:18 <morganfainberg> ok. so that covers those specs.
18:40:22 <morganfainberg> erm bps
18:40:31 <morganfainberg> since we don't have anything else on the agenda
18:40:42 <morganfainberg> we're going to call the meeting done 20 minutes early
18:40:49 <morganfainberg> please spend 20 mins and review code :)
18:40:49 <rodrigods> first time ever
18:40:52 <henrynash> oh boy!
18:40:56 <raildo> haha
18:41:00 <dolphm> \o/
18:41:02 <morganfainberg> since you've already set aside this time:)
18:41:07 <morganfainberg> #endmeeting