18:00:01 <morganfainberg> #startmeeting Keystone
18:00:02 <rharwood> I think it's rally before us?
18:00:03 <openstack> Meeting started Tue Sep 30 18:00:01 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:06 <openstack> The meeting name has been set to 'keystone'
18:00:32 <dolphm> \o/
18:00:37 <morganfainberg> So the meeting should be relatively quick overall then we have plenty to discuss for the summit planning (sessions, etc)
18:00:50 <morganfainberg> #topic Juno RC1
18:00:51 <bknudson> dolphm: no weight on your shoulders anymore.
18:00:52 <morganfainberg> dolphm, o/
18:01:04 <dolphm> WE CUT JUNO RC1!
18:01:11 <morganfainberg> woohoo!
18:01:11 <dolphm> nice work, everyone!
18:01:18 <nkinder> yay!
18:01:27 <bknudson> is there a branch for rc fixes?
18:01:32 <ayoung> nice swan song Dolph
18:01:35 <morganfainberg> bknudson, yes proposed/juno
18:01:36 <dolphm> we seriously flew the RC bugs this cycle, which was really impressive. so, big thanks to everyone who contributed!
18:01:57 <dstanek> o/
18:02:13 <dolphm> 53 bugs got fixed total :)
18:02:14 <nkinder> so is there a LP tag that we should add for proposed/juno bugs?
18:02:23 <lbragstad> wow
18:02:28 <morganfainberg> nkinder, juno-rc-potential i think? /me checks
18:02:38 <dolphm> nkinder: yes, so we're still using juno-rc-potential
18:02:51 <dolphm> for things that can potentially be backported
18:02:58 <nkinder> ok, I have a few to add to that (the LDAP ones from this morning)
18:03:09 <dolphm> fixes should land to master first, then be backported after they land
18:03:12 <dolphm> nkinder: ++
18:03:27 <morganfainberg> nkinder, yeah the two ldap ones you proposed fixes for should both hit RC2 if we're cutting an RC2
18:03:32 <topol> o/
18:03:51 <stevemar> nkinder, utf8 problems again for ldap?
18:03:51 <bknudson> do we have an etherpad for rc-potential reviews?
18:04:04 <morganfainberg> #link https://bugs.launchpad.net/keystone/+bugs?field.tag=juno-rc-potential
18:04:05 <dolphm> bknudson: i'll keep using the same gist
18:04:08 <stevemar> bknudson, i've been a fan of https://gist.github.com/dolph/651c6a1748f69637abd0
18:04:09 <nkinder> stevemar: yep, a regression from a fix that went into RC
18:04:13 <morganfainberg> bknudson, and the gist
18:04:23 <nkinder> stevemar: https://review.openstack.org/#/c/125097/
18:04:46 <stevemar> dolphm, star that review ^
18:04:49 <dolphm> stevemar: done
18:04:50 <nkinder> stevemar: and https://review.openstack.org/#/c/125083/
18:04:58 <stevemar> dolphm, and this one v
18:05:04 <stevemar> err ^
18:05:06 <dolphm> stevemar: that's already on https://gist.github.com/dolph/651c6a1748f69637abd0
18:05:17 <stevemar> :P
18:05:41 <morganfainberg> defintely awesome work everyone!
18:06:08 <dolphm> ++ i don't have much else to say, other than it already looks like we'll have an RC2 in a couple days due to the one fix that nkinder proposed this morning
18:06:32 <morganfainberg> and if you run into any bugs, please please say somthing sooner vs later :)
18:06:40 <dolphm> yes, open bugs ASAP
18:06:57 <dolphm> even if you're not confident it's a bug - it's the best way to raise a red flag at this point in the cycle
18:07:02 <morganfainberg> ++
18:07:25 <henrynash> morganfainberg: I think I’ve got one on the federation sql migration downgrade…does handle teh FKs
18:07:36 <henrynash> will raises asap
18:07:38 <morganfainberg> henrynash, thanks
18:07:50 <morganfainberg> On a related note....
18:07:53 <morganfainberg> #topic Juno release notes
18:07:58 <morganfainberg> dolphm, all you again
18:08:13 <dolphm> ack
18:08:15 <gyee> just curious, how many deplolyments support downgrade in production, I bet none
18:08:40 <dolphm> so i was excited to see that some release notes had already been written yesterday
18:08:52 <dolphm> but i spent most of the day filling out as many as i could:
18:08:55 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Identity_.28Keystone.29
18:09:20 <stevemar> i wonder who wrote them =\
18:09:24 <dolphm> i'd appreciate if everyone read through them, and contributed edits, things i overlooked, forgot about, etc
18:09:59 <morganfainberg> I have a couple small notes to add, I'll get them added today
18:10:07 <dolphm> everything is roughly sorted by how much awareness it should raise, because sure no one is going ot read more than a line or two from each section :)
18:10:13 <dolphm> otherwise, please have at it :)
18:10:26 <nkinder> dolphm: multi-backends isn't really called out separately
18:10:47 <nkinder> that and the fact that domains is supported for LDAP seems worthy of being called out
18:11:12 <topol> nkinder, https://review.openstack.org/#/c/125097/ looks very good!
18:11:16 <dolphm> nkinder: i half-covered that with "In the case of multiple identity backends..." since it wasn't entirely a new feature, but please do flesh it out!
18:11:50 <nkinder> dolphm: ok, I saw it was mentioned.  I'll try to flesh it out some more.
18:11:54 <henrynash> morganfainberg: (fyi, that bug raised: https://bugs.launchpad.net/keystone/+bug/1375937)
18:11:55 <uvirtbot> Launchpad bug 1375937 in keystone "Downgrade of federation extension can fail due to FKs" [Undecided,New]
18:11:55 <dolphm> nkinder: thanks!
18:12:08 <morganfainberg> henrynash, thanks! i'll look at it post meeting
18:12:32 <dolphm> henrynash: i assume we didn't catch that just because sqlite doesn't care about FK's?
18:12:41 <morganfainberg> dolphm, likely
18:12:42 <topol> dolph, Yay the release notes mentioned CADF for federation and role assignments
18:12:56 <stevemar> thats an impressive amount of stuff
18:13:06 * stevemar read over the release notes
18:13:17 <bknudson> you'd think the whole keystone problem would have been solved by now.
18:13:17 <henrynash> dolphm: yep - I found it while working https://bugs.launchpad.net/keystone/+bug/1363047
18:13:20 <uvirtbot> Launchpad bug 1363047 in keystone "test_sql_upgrade and live_test not working for non-sqlite DBs" [High,In progress]
18:13:20 <topol> stevemar +++ This a  great release to be associated with!!!
18:14:11 <dolphm> morganfainberg: that's all i've got
18:14:15 <morganfainberg> ok
18:14:20 <morganfainberg> #topic Bug Triage
18:14:48 <bknudson> There's no results for https://bugs.launchpad.net/keystone/?search=Search&field.status%3Alist=NEW&orderby=-id
18:14:50 <morganfainberg> I wanted to call out dolphm, stevemar, lbragstad for doing an amazing job in helping to get the untriaged bugs under controll
18:15:01 <morganfainberg> lots of people helped as well
18:15:25 <morganfainberg> but i know that those three cleaned up a bunch
18:15:33 <morganfainberg> in general great work everyone!
18:15:39 <dstanek> ++
18:15:44 <bknudson> are we supposed to also look at the bugs in the link for "keystone in Ubuntu"
18:15:53 <morganfainberg> bknudson, not sure, are we?
18:16:01 <morganfainberg> bknudson, never looked there myself.
18:16:08 <lbragstad> bknudson: do you have a link?
18:16:18 <bknudson> it's right there on the https://bugs.launchpad.net/keystone/?search=Search&field.status%3Alist=NEW&orderby=-id page
18:16:24 <lbragstad> https://bugs.launchpad.net/ubuntu/+source/keystone
18:16:25 <dolphm> bknudson: we pass bugs back and forth on occassion, but those should be packaging bugs
18:16:26 <stevemar> https://bugs.launchpad.net/ubuntu/+source/keystone
18:16:35 <dstanek> bknudson: i don't think so - that is usually not stuff we can fix
18:17:07 <morganfainberg> in the next week i'll be turning on a bot that will report to #openstack-keystone untriaged bugs for all of the projects we control.
18:17:10 <bknudson> they do look like packaging bugs
18:17:29 <morganfainberg> it'll report current stats (count and a link to the list) about once every 2 hrs
18:17:31 <stevemar> then let packagers worry about it :P
18:17:54 <morganfainberg> while we all get email, sometimes a quick "oh look, here are some bugs no one has looked at yet" in IRC goes a long way
18:18:21 <stevemar> sounds like a good idea
18:18:26 <nkinder> morganfainberg: +1
18:18:27 <dstanek> morganfainberg: i just wrote a script yesterday that runs every 5 minutes and looks for new bugs - trying to combite it with dolphm's gerrit script
18:18:27 <morganfainberg> this is based on tripleo's untriaged bot, i think there is some benefit to try and get eyes on bugs as quickly as possible.
18:18:40 <morganfainberg> dstanek, i'd love to get a gist for it as well.
18:18:49 <morganfainberg> dstanek, let me know i'm totally game to combine efforts
18:19:19 <dstanek> morganfainberg: i have a few more small tweaks, but i'll publish it - it uses terminal-notifier
18:19:24 <topol> dont join forces... do a bake off. Fight Fight Fight :-)
18:19:25 <morganfainberg> dstanek, cool
18:19:36 <morganfainberg> we're going to skip around the agenda really quickly
18:19:41 <dolphm> dstanek: gerrit-growler?
18:19:50 * topol probably better to join forces
18:20:05 <morganfainberg> hehe
18:20:18 <dstanek> dolphm: i had a bunch of issues with the growler stuff - so i went to pync
18:20:55 <lbragstad> dstanek: I submitted some patches to gerrit-growler for a couple of the things I was seeing
18:21:08 <morganfainberg> i need to get gerrit-growler working
18:21:15 <dstanek> dolphm: haha, yes gerrit-growler
18:21:32 <dolphm> dstanek: we'll have to catch up post-meeting, i'm curious what you're doing
18:21:33 <dstanek> dolphm: i did surgery on it to not just look at starred reviews
18:21:44 <stevemar> i guess the last topic is the design sessions?
18:22:01 <morganfainberg> #topic Hierarchical Multitenancy Patches
18:22:14 <morganfainberg> #link http://paste.openstack.org/show/116850/
18:22:19 <stevemar> op - nvm mind, multiprojectcy first
18:22:31 <morganfainberg> rodrigods and raildo wont be here today, but please review the multitenency stuff
18:22:43 <bknudson> fancy
18:23:13 <bknudson> is this still in a topic branch?
18:23:13 <morganfainberg> we'd like to get it moving again, a lot of people are interested in it
18:23:18 <bknudson> (does it need to be?)
18:23:23 <stevemar> bknudson, that is the fanciest paste i've ever seen
18:23:23 <morganfainberg> bknudson, i think so. but it doesn't need to be now
18:23:28 <stevemar> yes it's still in a feature branch
18:23:59 <samuelmz> I'm here o/
18:24:04 <morganfainberg> samuelmz, welcome.
18:24:05 <samuelmz> If you have question about that
18:24:11 <stevemar> thats a lot of reviews
18:24:19 <morganfainberg> samuelmz, anything you want to add as commentary?
18:24:47 <samuelmz> no .. I'm preparing a script for setting up the environment to test everything
18:24:59 <bknudson> devstack?
18:25:02 <samuelmz> yes
18:25:23 <samuelmz> you also use it, don't you? :-)
18:25:34 <ayoung> from time to time
18:25:40 <bknudson> if it's in devstack it'll be easy for me
18:26:10 <samuelmz> or if you prefer, I can provide an instance with the code deployed .. and then you can make the calls
18:26:43 <morganfainberg> samuelmz, having it as part of devstack will be nice for people wanting to play with the code and/or when it comes time for integration work cross projects and testing
18:27:11 <samuelmz> yes
18:27:26 <samuelmz> if you want to try it out .. ssh stack@ssh.cloud2.lsd.ufcg.edu.br -p 10090
18:27:35 <samuelmz> password is stack
18:28:01 <morganfainberg> samuelmz, FYI i wouldn't put passwords in this channel, it's logged and very public.
18:28:10 <morganfainberg> samuelmz, unless that is planned to be a very short lived instance
18:28:21 <samuelmz> yes, it is
18:28:24 <morganfainberg> ok
18:28:47 <morganfainberg> anything else on Heirarchical stuff?
18:29:23 <morganfainberg> #topic Kilo Summit Sessions Discussion
18:29:28 <morganfainberg> The big topic
18:29:31 <morganfainberg> #link https://etherpad.openstack.org/p/kilo-keystone-summit-topics
18:29:35 <morganfainberg> this is the *correct* etherpad
18:30:10 <morganfainberg> the old etherpad https://etherpad.openstack.org/p/keystone-kilo-summit-sessions is slowly being moved over
18:30:21 <morganfainberg> please feel free to jump in and discuss the topics there
18:30:41 <morganfainberg> dstanek, o/ you have a specific sub-topic here
18:31:08 <samuelmz> morganfainberg, I changed that instance credentials .. anyone who'd like to test may feel free to ask me for them
18:31:20 <morganfainberg> samuelmz ++ good call.
18:31:55 <ayoung> I started pulling all the token sessions into one block
18:32:05 <morganfainberg> ayoung thanks!
18:32:11 <marekd> o/ so i was thinking about adding gerrit testsuite for federation - so we can test the full workflow, not mocked saml assertions.
18:32:21 <ayoung> line 12
18:32:35 <ayoung> marekd, maybe...
18:32:38 <marekd> i think i added this in one of previous etherpads. If it wasnt moved to the new one I will add it.
18:32:42 <marekd> ayoung: why maybe?
18:32:49 <marekd> ayoung: you think it's a bad idea?
18:32:58 <afaranha> morganfainberg: Do we have place to discuss about the multi-level policy files?
18:33:05 <ayoung> marekd, no good idea
18:33:09 <ayoung> but, we were saying this:
18:33:12 <dstanek> i have a few code reviews for messing with passwords that are really old - i stopped working on them before the last summit when we said maybe we don't want to expand identify
18:33:18 <ayoung> thereare like, 10 different LDAP setups we need to support
18:33:22 <ayoung> we can't support them all
18:33:26 <henrynash> afarnha: multi-level?
18:33:30 <nkinder> yeah, I just added LDAP to the CI item
18:33:31 <morganfainberg> the the main idea for the etherpad is trying to hammer out what the sessions should be, similar to the last summits. if something is a "yes we should do it" we're not going to have a whole summit session to agree to it.
18:33:36 <dstanek> in the last summit we talked about splitting it out and i'm wondering if that's worth talking about
18:33:36 <ayoung> lets offload to the various organizations to run a check job for their setup
18:33:39 <marekd> ayoung: i find myself quite often writing unit tests and later trying it on my own setup and pasting the comment "worked on my testbed"
18:33:43 <ayoung> and maybe SAML is treated the same way
18:33:55 <dstanek> also there seems to be no demand anymore for the password features i was working on
18:34:07 <bknudson> I'm still not sure what the CI will look like in K...
18:34:09 <ayoung> we set up a few SAML providers and external check jobs to run against them
18:34:13 <morganfainberg> we ill have 7 session slots, a 1/2 day meetup (on friday) [think like the mid-cycle format], and pods just like the last time.
18:34:18 <bknudson> are they expecting us to provide our own tempest-style tests?
18:34:19 <morganfainberg> s/ill/will
18:34:25 <afaranha> henrynash: yes, in the etherpad is tagged as "(HN) Multi-domain policy files, roles etc.", just saw it
18:34:29 <marekd> ayoung: but we *recommend* service provider stuff (mod_shib) and we need to be sure it will smoothly work with apache and keystone
18:34:47 <bknudson> should our "unit" tests be doing testing based on whether the service is available?
18:34:52 <ayoung> marekd, yeah, and maybe we do that and openldap as supported by devtack as the baseline
18:35:05 <bknudson> e.g., have tests in keystone/tests that run if mysql is avaialble
18:35:08 <henrynash> afaranha: yep, I put that there….was that what you were refering to - or something else?
18:35:29 <marekd> ayoung: anyway, thats my proposal. If ppl don't like it we will simply don't do that.
18:35:37 <bknudson> or postgres, or ldap
18:35:38 <morganfainberg> bknudson, afaict functional tests (our RESTful cases) should be run in-tree and should expand to cover mysql, pgsl, ldap, etc support.
18:35:42 <dstanek> bknudson: maybe for some optional tests, but those wouldn't be unit tests
18:35:54 <marekd> morganfainberg: dolphm i wil add the entry again if you let me. (unless you think it's really pointless at this early stage)
18:35:54 <morganfainberg> bknudson, integration (e.g. nova using keystone) would still be tempest
18:36:08 <morganfainberg> marekd, please add away
18:36:19 <afaranha> henrynash: yes, thats it, In the lab we have been working on that since a few months ago
18:36:36 <morganfainberg> marekd, anything that was not moved over from the old etherpad has strictly been because i haven't had a chance to do it, or i've been trying to consolidate some and working to figure that out
18:36:53 <marekd> morganfainberg: sure thing.
18:36:58 <morganfainberg> marekd, no harm in adding it back in if it's missing
18:37:23 <afaranha> I'd like to know what path should we follow, we sent a policy sample and we're already doing the fixes in it
18:38:03 <dstanek> morganfainberg: any thoughts on password features?
18:38:36 <ayoung> dstanek, rotation?
18:38:38 <morganfainberg> bknudson, so ideally we should work to make our functional tests work with *any* of the backends and then we can standup appropriate environments and test against each one. and/or mirror more "real" deployment choices [especially since we don't rely on other services at the moment, it gives us a lot of flexibility in what we can model in our testing]
18:38:47 <dolphm> morganfainberg: maybe you can inquire with HP folks about pw rotation and stuff while you're down there
18:38:56 <morganfainberg> dolphm, it's on my list of things to do.
18:39:05 <dstanek> ayoung: yes, and some of the other requested stuff (validation, etc.)
18:39:18 <gyee> dolphm, low priority, especially if we are separating out IdP from Keystone
18:39:22 <morganfainberg> dolphm, i'm in process of setting up meetings so i can figure out what all the demands are and see where everyone lies.
18:39:32 <ayoung> dstanek, would love to say "use LDAP for that"
18:39:39 <morganfainberg> s/lies/sees things/
18:39:41 <nkinder> ayoung: +1
18:39:53 <bknudson> but if you use LDAP now you don't have domains
18:39:56 <ayoung> dstanek, and...I think we can do that with multi LDAP backend
18:39:57 <dolphm> morganfainberg: ++ everyone lies
18:40:01 <morganfainberg> dolphm, hehe
18:40:04 <nkinder> bknudson: not true in juno though
18:40:14 <ayoung> bknudson, yes you can, you just need to have a config file per domain
18:40:26 <dolphm> and multiple ldap servers
18:40:29 <ayoung> nope
18:40:30 <dolphm> most likely, anwyay
18:40:31 <nkinder> dolphm: no
18:40:40 <bknudson> and apparently heat and other projects are expecting to be able to create users
18:40:41 <ayoung> can be in separate subtrees of one ldap server
18:40:48 <nkinder> you could use separate trees, or even just separate user filters in one tree
18:40:53 <nkinder> it's pretty flexible
18:40:55 <dolphm> ayoung: right, but i'm just guessing that's not how it'll be utilized most
18:41:11 <dolphm> nkinder: oh filters is an interesting approach
18:41:16 <dstanek> morganfainberg: let me know what you find out
18:41:20 <ayoung> dolphm, we don't want to support that
18:41:21 <dolphm> didn't think of that
18:41:24 <nkinder> dolphm: yeah, was thinking about that yesterday
18:41:33 <morganfainberg> dolphm, especially relevant on the topic of people using AD.
18:41:45 <morganfainberg> amazing what filters they like to use to isolate users int he tree
18:41:53 <topol> nkinder can you elaborate?
18:41:54 <ayoung> filter or other LDAP approaches should be acceptable
18:41:55 <nkinder> memberOf: <domainA>
18:41:57 <morganfainberg> not necessarily openstack specific
18:42:16 <nkinder> basically turn domains into LDAP groups and determine what domain(s) a user could be in.  Lots that can be done there.
18:42:32 <ayoung> topol, similiar to your origianal implementation....
18:42:44 <nkinder> you could even have a single user span multiple domains, which is an interesting thought
18:42:52 <ayoung> shudder
18:42:58 <topol> ayoung, Im sure way better than that monstrosity :-)
18:43:25 <ayoung> bottom line: we can make better use of LDAP, which already supports password policy
18:43:42 <ayoung> without anything new, we can do multiple domains, just high touch
18:43:46 <topol> nkinder, where were you two years ago, when folks kicked my ass over that :-)
18:43:59 <ayoung> topol, working on 389
18:44:02 <morganfainberg> ayoung, we will still have demand for SQL identity. but it'll mostly be for the service-user case and to support those who have historically used it.
18:44:29 <bknudson> the sql backend is unusable due to having requirements for passwords
18:44:37 <bknudson> that the sql backend doesn't support
18:44:48 <morganfainberg> ayoung, and/or keystone manages their users (not readonly). we may want to long term look at if we want to drop SQL identity and how to do the migrations.
18:45:06 <gyee> use certs for the server users
18:45:08 <morganfainberg> but i think the LDAP backend (read/write) is not fully baked enough as of yet to *really* be a full IDP backend.
18:45:13 <gyee> they are "internal users"
18:45:27 <bknudson> client certs seem like a good idea.
18:45:29 <nkinder> gyee: +1.  I like hte certs approach for service users
18:45:35 <bknudson> maybe have a cert field in the user table
18:45:37 <ayoung> morganfainberg, its beter than the SQL backend
18:45:45 <ayoung> its gotten more attention
18:45:48 <morganfainberg> ayoung, i'd say it's about the same.
18:45:50 <ayoung> certs ++
18:45:51 <topol> morganfainberg +++ I thought wrtie LDAP had all kinds of problems we were running from
18:45:54 <gyee> bknudson, no need for token, just straight cert auth
18:46:03 <gyee> service users are highly static
18:46:09 * topol it feels like throwback Keystone Thursday
18:46:16 <morganfainberg> ayoung, neither SQL nor read/write LDAP have gotten the love they need to be full featured
18:46:25 <ayoung> service users should be able to use X509 or Kerberos.
18:46:34 <nkinder> morganfainberg: yeah, that's pretty accurate
18:46:42 <ayoung> that is a ATM issue
18:46:55 <morganfainberg> remember, people will want username/password support.
18:47:07 <morganfainberg> you cna't eliminate it, you can make it the "less preferential" model.
18:47:19 <topol> morganfainberg +++
18:47:21 <bknudson> we should be able to make it so that no password is required
18:47:26 <morganfainberg> bknudson, absolutely
18:47:35 <gyee> morganfainberg, keystone identity sql backend doesn't even support password policies at the moment
18:47:52 <gyee> min, max password lenght, password composition, etc
18:47:54 <bknudson> gyee: the question is, should it?
18:48:02 <bknudson> if you can use ldap, why reimplement it?
18:48:03 <nkinder> morganfainberg: one nice thing about certs for service users is that it allows us to get passwords out of files in other services
18:48:06 <topol> gyee, I though keystone identity was frankly a toy
18:48:17 <topol> (sql identity)
18:48:20 <gyee> topol, damn straight!
18:48:22 <morganfainberg> nkinder, i agree. doesn't mean anyone/everyone would use it.
18:48:32 <nkinder> morganfainberg: yeah, I agree
18:48:48 <nkinder> morganfainberg: but it means we shouldn't try to make passwords a first-class solution
18:49:11 <morganfainberg> nkinder, we should make sure they work, and we can't eliminate them. but I agree certs for service users is a great model
18:49:18 <ayoung> gyee, added a middleware section on the etherpad to cover the service users issue.
18:49:27 <gyee> ayoung, thanks
18:49:37 <topol> I viewed sql identity as a gateway drug. Gave you a chance to play with things before trying the hard stuff
18:49:46 <ayoung> gyee, jamielennox started an auth plugin review that is related, I think
18:49:48 <dolphm> topol: ++
18:49:49 <morganfainberg> heck, if service users also *always* used token binding... it would make that a significantly better / secure setup.
18:50:05 <gyee> topol, lets pow wow
18:50:25 <morganfainberg> gyee, i'll talk with you some about this when i'm up there next week :)
18:50:39 <bknudson> I thought we were saying no tokens for service users
18:50:55 <bknudson> just use your cert on the request and you're authenticated
18:50:55 <morganfainberg> bknudson, oh so x509 or similar direct to the endpoint?
18:51:01 <nkinder> morganfainberg: you're headed up this way?
18:51:03 <morganfainberg> bknudson, hm... i like that too
18:51:18 <morganfainberg> nkinder, yeah next week i'll be in PDX for the first 2 days then in Sunnyvale for a couple days
18:51:20 <gyee> bknudson, sure why not
18:51:24 <topol> bknudson I like that
18:51:38 <nkinder> morganfainberg: I wouldn't mind getting together with you and gyee to talk about some of this when you're in sunnyvale
18:51:40 <morganfainberg> bknudson, the question is does keystone then issue that cert?
18:51:42 <gyee> there's no one-size-fits-all, we optimize on behavior
18:51:48 <bknudson> of course not
18:51:54 <morganfainberg> nkinder, sounds good. gyee ^ :)
18:51:59 <bknudson> you get it from your ca
18:52:07 <nkinder> bknudson: ++
18:52:14 <topol> bknudson good answer
18:52:17 <gyee> barbican perhaps
18:52:28 <nkinder> gyee: chicken and the egg there...
18:52:30 <morganfainberg> bknudson, so the endpoint will need to call back to keystone to get user RBAC info for the service user then?
18:52:31 <topol> gyee+++ good backup
18:52:34 <lbragstad> yeah
18:52:49 <lbragstad> barbican would have to ask Keystone if the service had access to that cert?
18:52:52 <morganfainberg> bknudson, since the cert doesn't contain the attributes needed to directly cover policy enforcement
18:53:10 <morganfainberg> not the end of the world.
18:53:16 <morganfainberg> just something to consider
18:53:19 <gyee> there will be some bootstrapping involve
18:53:28 <gyee> between Keystone and Barbican
18:53:54 <morganfainberg> [7mins left in meeting]
18:54:00 <nkinder> Barbican doesn't really supply certs for infrastructure pieces (it's more for services that OpenStack provides)
18:54:12 <nkinder> more discussion for the summit... :)
18:54:36 <morganfainberg> there will definitely be at least 1 session on client/middleware
18:54:40 <morganfainberg> i can say that confidently
18:54:51 <bknudson> so at some point we decide what sessions we're going to hvae...
18:55:04 <morganfainberg> yep
18:55:48 <morganfainberg> i'll bug dolphm and get some insight on how this will end up working :) and we'll continue the discussion in the etherpad / -keystone
18:56:14 <ayoung> I have to say that with multi backends, and service users out of ldap...everything should be a user.
18:56:15 <topol> with 7 sessions I expect lots of merging... or lots of talk at the bar at nights
18:56:23 <ayoung> each endpoint, each compute node
18:56:26 <morganfainberg> topol, or in the pods.
18:56:34 <nkinder> topol: likely both :)
18:56:39 <ayoung> and then we say a user can have one (or more?) x509 certs associated
18:56:41 <bknudson> I'm not sure how well merging works... we've got 40 mins and we need to reach a conclusion.
18:56:46 <topol> or scotch in the pods. like last time
18:56:54 <dolphm> no paper cups
18:56:57 <samuelmz> morganfainberg, about the hierarchical multitenancy stuff
18:56:58 <dolphm> new rule
18:56:58 <morganfainberg> LOL
18:57:00 <gyee> haha
18:57:00 <samuelmz> morganfainberg, -> 10 steps to get a devstack with Hierarchical Projects and Inherited Roles working (http://paste.openstack.org/show/117237/)
18:57:07 <morganfainberg> samuelmz, thanks!
18:57:07 <topol> plastic ?
18:57:31 <bknudson> bring your own shot glass or flask
18:57:39 <dstanek> we really need a question for each session to answer to make sure we leave it knowing something got done
18:57:49 <lbragstad> ++
18:57:50 <gyee> is flask allowed on the plane?
18:57:58 <nkinder> dstanek: +1
18:58:00 <lbragstad> gyee: just make sure it's empty...
18:58:01 <topol> gyee if its empty
18:58:04 <morganfainberg> dstanek, agreed
18:58:06 <nkinder> gyee: if you drink it first, why not?
18:58:13 <gyee> hell yeah!
18:58:20 <morganfainberg> or a specific mission for the session
18:58:31 <morganfainberg> e.g. get details of XXX worked out.
18:58:48 <bknudson> maybe that would help us prepare better for the session, too
18:58:48 <nkinder> yeah, I really like the idea of setting a goal for each session
18:58:58 <dolphm> dstanek: ++
18:58:59 <dstanek> morganfainberg: i'd even make it more specific than that if we can
18:58:59 <topol> me too!!
18:59:03 <morganfainberg> dstanek, ++
18:59:19 <morganfainberg> ok we're out of time here. we can continue in #openstack-keystone
18:59:22 <morganfainberg> thanks for showing up!
18:59:28 <morganfainberg> #endmeeting