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