18:02:29 <morganfainberg> #startmeeting keystone
18:02:30 <openstack> Meeting started Tue Mar 31 18:02:29 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:33 <openstack> The meeting name has been set to 'keystone'
18:02:51 <morganfainberg> Hello everyone!
18:02:56 <samueldmq> :-)
18:03:07 <morganfainberg> So a couple quick things
18:03:23 <morganfainberg> Rc is next week. Please focus on bugs and bps that need review /code
18:03:42 <morganfainberg> The domain sql bp needs to be done by Thursday.
18:03:48 <morganfainberg> This Thursday.
18:03:50 <ayoung> link henrynash ?
18:04:04 <henrynash> it’s  in the meeting agenda
18:04:04 <morganfainberg> It's later in the agenda specifically ayoung
18:04:08 <ayoung> cool
18:04:16 <henrynash> #link https://review.openstack.org/#/c/163322/
18:04:29 <morganfainberg> #topic Hierarchical Projects support on Horizon
18:04:37 <morganfainberg> samueldmq: ericksonsantos o/
18:04:37 <samueldmq> o/
18:04:45 <ericksonsantos> :)
18:04:45 <samueldmq> hello, so ...
18:04:50 <samueldmq> ericksonsantos and I have been working on adding support for hierarchical projects on Horizon
18:04:56 <bknudson> guis are fancy!
18:05:01 <samueldmq> we then decided to add a point to this meeting to let you know what is going on
18:05:06 <ayoung> This is for Kilo?
18:05:10 <samueldmq> first, a blog post explaining what was implemented
18:05:18 <david-lyle> not Kilo
18:05:24 <ayoung> Ok
18:05:24 <samueldmq> ayoung, unfortunately no
18:05:39 <samueldmq> #link www.samueldmq.com/hierarchical-projects-on-horizon/
18:06:00 <samueldmq> there we explain the approach we took for this first implementation
18:06:15 <samueldmq> in which basically we show projects with their hierarchical name
18:06:30 <samueldmq> which is its own name + parents names, separated by slashes
18:06:47 <samueldmq> e.g GrandParent / Parent / Child
18:06:55 <samueldmq> and we have some screenshots :)
18:06:56 <bknudson> what if someone does hmt today, does horizon go crazy?
18:07:12 <ayoung> nah, it just ignores what it doesn't know about.
18:07:23 <ayoung> You can;t create a nested project in Horizon today, right?
18:07:24 <bknudson> I like the \ for the separator, just like windows.
18:07:31 <samueldmq> ayoung, ++ no you cant
18:07:46 <samueldmq> if you guys want to try it out ...
18:07:51 <samueldmq> we have a demo running on 150.165.15.68, with Horizon credentials admin/nomoresecrete
18:08:03 <morganfainberg> best kind of feature. The kind that can be ignored if you don't want to use it ;)
18:08:03 <samueldmq> we will keep it open until Saturday, and then change the password
18:08:19 <ayoung> I assume you are working with UX type people to make sure that the choices you are making are sane?
18:08:33 <samueldmq> and if someone still wants to have access, can ask myself or ericksonsantos
18:09:00 <samueldmq> ayoung, yeah we already worked with some horizon guys, but this is a first implementation
18:09:10 <samueldmq> ayoung, which means it can be changed
18:09:23 <samueldmq> ayoung, that's the reason we are requesting your feedback
18:09:31 <samueldmq> so feel free to try it out and give some feedback :)
18:09:37 <morganfainberg> s/can/will be (but because it'll evolve)
18:09:38 <samueldmq> morganfainberg, that's all I think
18:09:47 <samueldmq> morganfainberg, sure
18:09:49 <ayoung> samueldmq, we're Keystoners.  We are not UX people.  We make UGLY UI
18:09:50 <bknudson> neat
18:10:19 <samueldmq> ayoung, some ppl may have some ux background
18:10:22 <ayoung> david-lyle, who from the Horizon side has provided input?
18:10:29 <samueldmq> ayoung, I'm a keystoner and was able to make it happen :)
18:10:39 <ayoung> samueldmq, my point exactly
18:10:41 <morganfainberg> samueldmq: don't advertise too loudly, you'll get roped in on more stuff. ;)
18:10:44 <ayoung> I know better than to write UI
18:10:54 <david-lyle> I have and I think samueldmq is working with Piet
18:10:59 <morganfainberg> If you write good UI.
18:11:01 <samueldmq> morganfainberg, k :)
18:11:01 <david-lyle> at least I hope
18:11:22 <samueldmq> ayoung, didnt intend to be annoying, sorry :)
18:11:29 <ayoung> no, not at all
18:11:30 <samueldmq> david-lyle, yes we are working with Piet's team
18:11:30 <david-lyle> Piet is cordinateing most of the UX work in horizon these days
18:11:43 <samueldmq> david-lyle, ++
18:11:45 * morganfainberg tosses samueldmq at david-lyle "he says he can do UI. I'm sure he can do UI design for horizon and all the keystone stuff he is doing today too!" /snark
18:11:52 <ayoung> samueldmq, and it is great you are doing this.  I just want to make sure you are getting feedback fromthe right folks
18:11:54 <morganfainberg> ;)
18:12:22 <samueldmq> ayoung, yeah getting feedback from ppl from UX (Piet's team, as david-lyle said)
18:12:27 <ayoung> good
18:12:31 <samueldmq> ayoung, and yours as well, just to add
18:13:02 <samueldmq> morganfainberg, not that much :p
18:13:05 * morganfainberg can complain about ux, but can't design a UI to save a life (and that is the story I am sticking to...)
18:13:17 <samueldmq> morganfainberg, our implementation is simple and we worked hard (even if it was simple )
18:13:25 <ayoung> OK...we have the link.  we'll beat on it.  Next?
18:13:37 * morganfainberg hides graphic arts portfolio and previous UI design under the rug.
18:13:44 <morganfainberg> Yes next topic.
18:13:51 <samueldmq> k thanks :)
18:14:01 <morganfainberg> #topic Domain-SQL, final reviews
18:14:08 <morganfainberg> henrynash: o/
18:14:24 <henrynash> ok, so this is the last (server) piece of domain-specific sql
18:14:28 <morganfainberg> henrynash: I have feedback on fixing the race. But I'll step in after you speak
18:14:31 <henrynash> #link https://review.openstack.org/#/c/163322/
18:14:32 <ayoung> LDAP only makes sense to me.  Any need for SQL?
18:14:44 <henrynash> ayoung: ?
18:14:56 <morganfainberg> henrynash: a comment I made on the review.
18:14:57 <bknudson> I'm ok with documenting limitations for an experimental feature.
18:15:14 <ayoung> henrynash, is there a demand for sql idenityt in a domain specific config?
18:15:20 <bknudson> needs to be fixed to get rid of experimental.
18:15:21 <morganfainberg> bknudson: ++ that might be the way to land it all in kilo vs the fix I am thinking.
18:15:41 <henrynash> morganfainberg: yes, I saw that…although I think we have seen demand for the sql driver specification…ayoung, didn’t you see ause for this
18:15:45 <henrynash> bknudson: agreed
18:15:57 <ayoung> henrynash, wasn't me, but I can see it if I squint
18:16:17 <ayoung> two caompnies want to keep their users in separeate databases for SOX or some other reason
18:16:19 <henrynash> morganfainberg: I’ll investigate
18:16:29 <ayoung> but, I thought LDAP was the primary driver.
18:16:30 <morganfainberg> henrynash: until we support multiple sql pools/connections it is fair to say the main driver is sql vs a domain specific. But that's my view.
18:16:48 <ayoung> So, talking practial, is there any real demand for sql, or are we just being thorough?
18:16:54 <morganfainberg> And override any domain (even default) to use ldap if you want something like that.
18:16:55 <henrynash> ayoung: I thought we saw a use of haveing a specific domain (sql) for service users
18:17:26 <ayoung> henrynash, that is different.  That would still be in the main identity backend
18:17:43 <henrynash> ayoung: it *could* be
18:17:53 <morganfainberg> henrynash: I'm just saying we invert the use-case, override default domain to be ldap, all domains without a specific driver are sql.
18:18:20 <morganfainberg> So you don't even have to check if there are multiple sqls, just "you don't" do it at all.
18:18:26 <henrynash> morganfainberg: I think we test that exact case in the unit tetss
18:18:29 <ayoung> henrynash, I thought the expectation was  sql for the main one,  supporting multiple domains.  LDAP in domain specific backends,  to allow for live deployment of new LDAP servers in B2B cases
18:19:11 <morganfainberg> henrynash: we could just say sql isn't domain specific. *shrug* it would solve the sql driver check.
18:19:15 <ayoung> morganfainberg, I think that is a good approach, at least for Kilo.  If we do that, and it proves to limiting, we do more in Liberty
18:19:19 <henrynash> ok, so action is for me to confirm wheteher we can bypass the problem in this fashion
18:19:19 <bknudson> ayoung: I think that is the expectation but it's not how it's implemented now.
18:19:35 <ayoung> bknudson, yeah, that was my understanding
18:19:49 <morganfainberg> henrynash: for the race: document it, *or* use optimistic locking.
18:20:02 <henrynash> morganfainberg: agreed
18:20:05 <bknudson> I'm fine with documenting it.
18:20:30 <morganfainberg> henrynash: if optimistic locking is easy do that. Documentation is minimum for Thursday this week.
18:20:31 <bknudson> please update the review with the known limitation
18:20:45 <henrynash> morganfainberg: ++
18:20:55 <morganfainberg> We can fix the locking in liberty if it is too much to do by Thursday.
18:21:31 <henrynash> morganfainberg: and when you say the race/locking…you mean the sql issue or teh get/update of configs not being atomic
18:21:37 <morganfainberg> Yep
18:21:55 <morganfainberg> You make the workflow update where thing = what you have now
18:22:13 <morganfainberg> And if that doesn't update any rows, you know the data has changed.
18:22:38 <morganfainberg> It's the same way we handle consuming trusts with limited uses.
18:22:48 <bknudson> the code now updates every row in a separate transaction
18:22:56 <bknudson> I think?
18:23:05 <henrynash> sorry, for clarity which issue are you referring to….teh get/update issue?
18:23:10 <henrynash> bknudosn: yes
18:23:22 <morganfainberg> Yes the get/update
18:23:27 <bknudson> each config option is a row
18:23:30 <henrynash> morganfainberg: yes, I look at what we did for trusts etc.
18:23:42 <henrynash> morganfainger: ok, thx
18:23:58 <henrynash> ok, I think I got what I need to do by Thursday
18:24:11 <ayoung> henrynash, shout if you need help
18:24:18 <henrynash> ayoung: thx
18:24:39 <morganfainberg> henrynash: don't worry too much about get/update by thurs. Like I said liberty we can work on that.
18:25:05 <morganfainberg> #Topic rc bugs
18:25:10 <henrynash> morganfainberg: agreed…and I’ll buy a coconut to to any customer taht finds that in Kilo anyway
18:25:35 <morganfainberg> Please do not assign bugs to the rc milestone unless they are really a blocker for release. When in doubt, bug me.
18:26:01 <henrynash> morganfainberg: apologies, guilty…but couldn’t work out how to use teh rc.potential tag?
18:26:03 <bknudson> are there any blockers?
18:26:03 <morganfainberg> At this point unless it is a show stopper we aren't adding it to the rc list.
18:26:23 <morganfainberg> henrynash: lp was being dumb I couldn't set it either.
18:26:59 <morganfainberg> bknudson: the critical security one, the high prio ones. The others should all be in progress and easy-ish to land.
18:27:19 <morganfainberg> bknudson: there is also an index on a sql table that should land if at all possible.
18:27:31 <ayoung> Do we have a link/query for RC bugs
18:27:35 <lbragstad> https://launchpad.net/keystone/+milestone/kilo-rc1
18:27:40 <lbragstad> #link https://launchpad.net/keystone/+milestone/kilo-rc1
18:28:31 <bknudson> probably shouldn't be wishlist bugs on here...
18:28:32 <morganfainberg> Oh the trustor disabled =403 not 404. That is  not api breaking to fix. And should be fixed.
18:28:49 <dstanek> bknudson: maybe someone really, really wants it
18:28:57 <bknudson> if you wish hard enough...
18:29:00 <morganfainberg> henrynash: hey that bug got back on the milestone! :P
18:29:10 <henrynash> which one?
18:29:19 <morganfainberg> Or lp is dumb
18:29:23 <morganfainberg> The wish list one.
18:29:49 <bknudson> seems like release-blocking should be limited to something that is really critical or can't be backported.
18:29:54 <henrynash> I never touched it, guv
18:30:44 <morganfainberg> bknudson: wish list removed. The other bugs are like I said in progress and should land for "ux/this would suck but if it doesn't land by Friday I'm ok punting them"
18:30:59 <morganfainberg> Except the high prio ones.
18:31:01 <ayoung> morganfainberg, I'll take https://bugs.launchpad.net/keystone/+bug/1430951  which was triaged but unassigned
18:31:02 <openstack> Launchpad bug 1430951 in Keystone "Revocation causes duplicate (and overly broad?) events in revocation table" [High,Triaged] - Assigned to Adam Young (ayoung)
18:31:07 <henrynash> is there a kilo-rc-potential tag?
18:31:08 <morganfainberg> ayoung: thanks.
18:31:29 <morganfainberg> henrynash: there is. Just tag the bug. But to be fair I don't want to add more to that list.
18:31:32 <lbragstad> I think there are only a couple that don't have patches proposed for review
18:31:42 <morganfainberg> Unless it is really a show-stopper.
18:31:44 <bknudson> I think there's already a review for https://bugs.launchpad.net/keystone/+bug/1430951
18:32:23 <stevemar> bknudson, link it in the bug?
18:32:47 <bknudson> can't find it now.
18:33:16 <morganfainberg> Ok let's move on, I have one more item and we can be done early ;)
18:33:21 <bknudson> found it? https://review.openstack.org/#/c/141854/
18:33:23 <ayoung> I'll make sure it is covered, either by existing review or new code
18:33:39 <bknudson> oh, that was similar but not the same.
18:33:41 <ayoung> Nope, that is a different issue
18:33:47 <ayoung> I think I actually like his approach there
18:33:59 <stevemar> similar
18:34:04 <morganfainberg> #topic Summit planning
18:34:14 <lbragstad> whoop whoop!
18:34:17 <stevemar> ohhh summit planning... neat
18:34:29 <lbragstad> get ready Canada
18:34:34 <ayoung> So, instead of hanging out at the Hotel bar buying expensive scotch, we each pick up a bottle and share.
18:34:44 <ayoung> That's really all I've got.
18:35:00 <morganfainberg> #link https://etherpad.openstack.org/p/Keystone-liberty-summit-brainstorm
18:35:07 <lbragstad> ayoung: are we getting Chocolate stout shakes?
18:35:14 <morganfainberg> I will send the link via the ml as well.
18:35:18 <ayoung> I really didn't care too much for them
18:35:21 <morganfainberg> Feel free to toss ideas there.
18:35:28 <ayoung> So...let's come up with something else.
18:35:40 <morganfainberg> I don't have the specifics on how many slots fishbowl or otherwise we will get.
18:35:53 <morganfainberg> In general I want this summit to be more like what our mid cycle has been.
18:36:21 <morganfainberg> So, unless the next PTL changes that idea (if I'm not ptl next cycle) let's roll with that plan.
18:36:34 <morganfainberg> Get specs hashed out, etc.
18:37:02 <ayoung> morganfainberg, you keep hoping....
18:37:19 <morganfainberg> I also would like to see next cycle a stability / performance cycle with very low numbers of features. (Again subject to change with potential alternative PTL)
18:37:26 <morganfainberg> Ok that's all I have
18:37:34 <morganfainberg> #topic open discussion
18:37:42 <morganfainberg> Any thing else?
18:38:04 <jamielennox> i have a small one, henrynash -1ed me on https://review.openstack.org/#/c/162525/ because we don't do it in keystone
18:38:22 <jamielennox> is there a reason we don't, or just because i haven't written it yet
18:38:23 <lbragstad> morganfainberg: when do you want to have ideas hashed out based on the etherpad?
18:38:23 <henrynash> quilty as charged, mlud
18:39:11 <henrynash> my -1 was about whether our test apis are part of out api documentation
18:39:13 <bknudson> the client libs are different than keystone server wrt docs, so I don't think they both need to be the same.
18:39:14 <morganfainberg> lbragstad: start now. We will circle up on it all on subsequent meetings and elsewhere.
18:39:32 <lbragstad> morganfainberg: ok, cool. Then group into buckets accordingly?
18:39:33 <jamielennox> bknudson: there's also no reason to do it in server docs either
18:39:38 <morganfainberg> lbragstad: it'll be open till we have a schedule. ;). Yep
18:39:42 <bknudson> does keystoneclient provide fixtures?
18:39:54 <jamielennox> henrynash: IMO tests are not public api, we can change, rename at will
18:39:54 <henrynash> bknudson: agreed they are different, but not sure why we would make it different in this particular case
18:40:09 <jamielennox> bknudson: yes, but they are in the public area, not the tests dir
18:41:00 <bknudson> I'm fine with skipping the tests in docs.
18:41:14 <morganfainberg> The official line is tests are public in that they exist. But nothing guaranteed beyond that.
18:41:23 <morganfainberg> So yeah we could skip the docs.
18:41:26 <jamielennox> we just renamed ksc/tests/* ksc/tests/unit/* so there's no compat guarantee
18:41:29 <bknudson> we don't keep them up to date anyways.
18:41:57 <morganfainberg> jamielennox: no tests do not have a compat guarantee.
18:42:09 <henrynash> jamielennox: ok, I’ll remove my -1 and I’ll submita patch for the server to remove the tests from teh api docs as well
18:42:35 <jamielennox> henrynash: cheers
18:42:44 <henrynash> good to have raised
18:43:08 <jamielennox> actually on that dstanek did you ever figure out moving the apidoc ext to oslo - or what the pbr issue was that needs it in each repo?
18:43:30 <jamielennox> i see notes all through there about various bugs and they mostly seem fixe
18:43:31 <jamielennox> d
18:43:34 <dstanek> jamielennox: for my two api doc reviews?
18:43:39 <bknudson> I tried to turn on warnings are errors in oslo.config and ran into that apidoc issue.
18:44:16 <bknudson> there was a thread on the mailing list recently about pbr release.
18:44:18 <dstanek> my understanding is that the issue isn't fixed yet in the released pbr; my changed was merged, but because of other brokeness they have been releasing pbr from a branch
18:44:27 <jamielennox> for example https://github.com/openstack/keystone/blob/master/doc/ext/apidoc.py#L15
18:45:19 <bknudson> https://bugs.launchpad.net/pbr/+bug/1260495 -- we need fix released.
18:45:21 <openstack> Launchpad bug 1260495 in python-keystoneclient "Setting autodoc_tree_index_modules makes documentation builds fail" [Low,Confirmed] - Assigned to David Stanek (dstanek)
18:46:17 <jamielennox> ah ok, i guess i just saw the age and assumed it would be out, i only poked around it briefly and then just c&p the extension
18:46:26 <dstanek> yeah, maybe i'll look at pbr and see if i can help fix the issues they are having
18:46:41 <jamielennox> but it's now in most repos i set up
18:47:50 <morganfainberg> Anything else? Before we call it a bit early?
18:47:56 <morganfainberg> 3...
18:48:09 <dstanek> jamielennox: the fix i did? in what repos?
18:48:27 <jamielennox> dstanek: i copy the doc/ext/apidoc.py file to other repos
18:48:40 <jamielennox> recently ksc-kerberos doa-kerberos and something else i can't remember
18:48:46 <dstanek> jamielennox: ah, that can be deleted after pbr is fixed
18:48:50 <jamielennox> yep
18:48:59 <jamielennox> didn't know about there release issues
18:49:10 <dstanek> we were the only project effected by the fix since we were the only ones using the feature
18:49:39 <ayoung> jamielennox, do I need an updated client to test the last DOA Federation code?
18:49:58 <jamielennox> ayoung: no i don't think so
18:49:59 <stevemar> shouldn't
18:50:03 <ayoung> OK
18:50:03 <morganfainberg> Let's move these
18:50:10 <morganfainberg> Convos to -keystone
18:50:14 <stevemar> k
18:50:18 <morganfainberg> They aren't needed for the whole team.
18:50:33 <morganfainberg> thanks all! Rc next week! Review code!
18:50:41 <morganfainberg> #endmeeting