18:01:20 #startmeeting keystone 18:01:21 Meeting started Tue May 5 18:01:20 2015 UTC and is due to finish in 60 minutes. The chair is dstanek. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:26 The meeting name has been set to 'keystone' 18:01:32 #topic Reminder: No Meeting 5/19 or 5/26 (Summit and Tuesday post summit) 18:01:41 the topic says it all. unless there are complaints i'll move on 18:01:41 hi 18:02:18 dstanek: should be 'and' in between the dates! 18:02:20 i'll take that as a nobody cares! 18:02:39 I hope everyone had a nice Star Wars day yesterday 18:02:54 #topic Midcyle Meetup Wiki Page 18:02:59 yay mid-cycle! 18:03:11 has everyone had a chance to look it over? 18:03:21 #link https://wiki.openstack.org/wiki/Sprints/KeystoneLibertySprint 18:03:52 Don't all edit at once 18:04:28 ayoung, morganfainberg: anything new to report? 18:04:40 need a section on Boston hotspots :) 18:04:44 better register before the attendance cap is hit 18:04:52 #racetoregister 18:05:09 we need to register?! 18:05:14 gyee, we'll have that taken care of 18:05:28 already a wiki markup fail! 18:05:33 there is some interest in having us at the OpenStack Boston Meetup, which is that weekn, ednesday I think 18:05:34 o/ 18:05:39 registration in FIFO, so if the attendance cap is hit, just start taking people off the top of the list to make room 18:05:46 http://www.meetup.com/Openstack-Boston/ 18:05:53 Def not a hot spot 18:06:13 there is some travel support program to midcycle? :P 18:06:17 dolphm, ++ 18:06:21 Heh...It looks like he added us to the schedule already 18:06:36 "Keystone project team members in the house! We are working to secure a special open mic session with members of the OpenStack Keystone project. Details coming soon." 18:06:38 looks like date/time and location are still solid and we are just waiting for hotel info 18:06:39 ayoung, bars, nightclubs 18:06:56 I'll push on that 18:07:01 raildo, feel free to start biking north :) lol 18:07:08 #action ayoung to get hotel info for midcycle 18:07:11 gyee: i can't wait to see you dancing at a nightclub 18:07:20 david8hu, so, I'll start today \o/ 18:07:34 dstanek, guanum style 18:07:37 no one else scared what type of club gyee would goto? 18:07:56 raildo: we'll provide you support in spirit :) 18:08:00 topol: ! i haven't see you around these parts in a long time 18:08:14 topol, chess club? 0_o 18:08:20 dstanek. been on the road show. Finally back 18:08:23 is there anything else we need to do or document to make it easier for people to get approval? 18:08:27 lhcheng, thank you! ^^ 18:08:52 hotel is the obvious one, but ayoung just actioned himself for that 18:09:21 ayoung: will you send that information out on the mailing list once you get it? 18:09:43 yep 18:10:16 ok, i'm excited about Boston, but moving on 18:10:19 lbragstad, actually, probably will limit it to adding a link to that page and pinging the people registered 18:10:24 dstanek, my family doesnt recognize me either :-) 18:10:28 ayoung: that works 18:10:51 topol: road show usually == hair loss and frowns 18:11:05 moving on.... 18:11:27 lbragstad: i'm sure we'll be talking about it in meetings and such shortly after the update 18:11:38 #topic First Pass on Summit Sessions 18:11:46 #link https://libertydesignsummit.sched.org/type/design+summit/Keystone 18:11:55 I/ 18:11:55 has everyone had a change to look over the proposed schedule for Keystone events? 18:12:01 sortof 18:12:16 lots of work sessions. that doesn't sound super fun 18:12:20 i know it's a pain since you have to go into each one 18:12:21 I'm here sortof 18:12:22 dstanek: it's mostly Work session 18:12:44 I thought we had an etherpad with the session proposals. Have we overloaded that? 18:12:49 dstanek: how work sessions are going to be structured? 18:12:50 marekd: yes it is 18:13:08 hopefully we'll actually get stuff done during the work sessions 18:13:20 git pull before the session 18:13:22 ayoung: the ether pad was some of what I based things on. Most of the work sessions will be open. 18:13:36 marekd: i'm assuming similar to how we do mid-cycles so that we can get real things done while in person, but morganfainberg may have more specific plans 18:13:36 So we can use the ether pad for those. 18:13:45 dstanek: cool! 18:13:55 We also have one more fishbowl and work sessio. Still tbd 18:13:56 lets get the proposed topics at least in the Work Session titles 18:14:09 We cannot change work sessio. Titles 18:14:15 bleh 18:14:23 ayoung: yes, getting a list of possible sessions would be great 18:14:31 I hope those *other* projects dont steal our tablkes and signs this time 18:14:45 topol: work sessions are a dedicated room. 18:14:48 No tables. 18:14:52 yay! 18:14:54 We need a Keystone banner 18:14:57 i think the etherpad is a good start at that 18:15:00 topol, me and you are going to move bodies this time 18:15:01 are we expecting developers from other projects to show up at our work sessions? 18:15:01 Work sessions are in lieu of the tables. 18:15:03 as needed 18:15:06 if our table is occupied 18:15:17 ayoung: we need a logo 18:15:18 Feel free to use my hotel room :) 18:15:21 gyee, I can be the muscle. yes 18:15:24 they all look like they're pretty specific to keystone 18:15:39 bknudson: yes. If we want a specific group to cross over we can add another track. 18:15:39 can you now, topol? 18:15:43 except for office hours... are other projects doing office hours? 18:16:11 bknudson: I just put office hours as a "generic" session. 18:16:16 bknudson: to work with us, or against us? 18:16:20 by the end of the week we'll have nothing left for the mid-cycle? 18:16:28 bknudson: yay! 18:16:32 I wanted a way to know I hadn't scheduled a specific thing. 18:16:58 morganfainberg: can we add a bit to the 'Keyston: Work session' titles? 18:17:23 like 'Keystone: Work session: Documenation' for https://libertydesignsummit.sched.org/event/644a88dfa5feefaa99913440c7871e53#.VUkJAdN3lTY 18:17:36 of course correcting for my terrible spelling 18:17:56 dstanek: nope. We cannot change the work session titles. 18:18:16 we need to get the docs people to attend that one. 18:18:37 I added the docs track to the work sessio. For documentation. 18:18:49 morganfainberg: ok, bummer; i'm going to scrape our session and make it a little easier to read at a glance 18:19:10 dstanek, they are *mandatory* sessions 18:19:29 mandatory for who - cres? 18:19:31 cores? 18:20:02 #action dstanek to make a summary of work sessions 18:20:06 gyee: mandatory? 18:20:18 you can't skip out of them regardless of title 18:20:37 dstanek: we also need to figure out the other tbd fishbowl. 18:20:41 we'll all get ankle bracelets for the duration of the meetup to track us and ensure attendance 18:20:41 So recommendations. 18:21:08 gyee: i "probably" won't skip, but it would be nice to see topics at a glance 18:21:25 glance is boring 18:21:31 hah 18:21:58 i, for one, would like to see dstanek skipping 18:22:11 henrynash: so it shall be done 18:22:13 gyee: nothing is mandatory. I asked for few sessions so we can be in other project sessions more often this summit. 18:22:23 i may cartwheel too 18:22:26 dstanek: we also require a slow beard release 18:22:34 ++ 18:22:36 dolphm: ++++++++++++++++++ 18:22:39 on high speed film 18:22:47 dolphm: sorry, it's not long enough anymore for the tucking 18:23:07 dstanek: we require a fresh beard 18:23:10 hehe 18:23:14 ok, anyway.... 18:23:20 back to summit sessions 18:23:39 thoughts, recommendations or "i haven't look yet"? 18:23:57 the sessions look fine to me. 18:24:14 for me too. 18:24:19 we might be able to get something done this time. 18:24:56 yes, hopefully less crowded table situation 18:25:06 do we have a work room? 18:25:10 or does it move around? 18:25:14 or a pod? 18:25:20 dynamic room 18:25:20 y, like a pod 18:25:21 the ones in GA were awesome 18:25:28 bknudson: is moves around some but it's mostly the same room(s) 18:25:28 dynamic pod 18:26:19 next item? 18:26:20 alright, so if you haven't taken a look at morganfainberg's first pass at summit session, please do so soonish 18:26:21 but I like morganfainberg's advice, attend other services meetings too 18:26:21 The last fishbowl ayoung recommended an authz focused session (oauth-ish workflow for interacting with non Keystone Services) 18:26:21 why is "keystone stable driver interfaces" acronymed like it's a thing? 18:26:29 things like policy migrate have implications 18:26:32 morganfainberg, ++ 18:26:42 dolphm: ksdi = keystone driver interface 18:26:43 we need to clearly communicate that to them 18:26:47 morganfainberg: why 18:26:52 dolphm: to mirror the spec. 18:26:53 gyee, ++ 18:27:02 As that is what the spec has. 18:27:20 #topic Blueprint review 18:27:20 dolphm: I can easily change it. 18:27:21 nothing explicitly called out in the agenda 18:27:29 does anyone have any blueprints that need a review for not requiring a spec? 18:27:30 dolphm: doesn't matter to 18:27:32 Me. 18:27:46 So forgive me if I've missed this, but.... do we know exactly what the implications of the new governance model will be for Keystone? 18:27:47 yes, endpoint constraint enforcement 18:27:51 using oslo policy 18:27:56 geoffarnold, no clue 18:28:06 Do we have our tags lined up? ;-) 18:28:07 geoffarnold, my guess is minimal 18:28:08 are we getting kicked out of openstack? 18:28:14 bknudson, I sure hope so 18:28:17 geoffarnold: there is already decided *there will be* new governance model? 18:28:18 geoffarnold: uhh. Not a real change afaik 18:28:39 geoffarnold: do you have a link that shows the actual changes? 18:28:46 geoffarnold: at least nothing planned yet. 18:28:51 https://review.openstack.org/#/c/174799/5/specs/keystonemiddleware/endpoint-enforcement-middleware.rst 18:28:59 gyee: there are competing reviews for endpoint enforcement 18:29:00 dstanek, BTW, I did add something to the agenda...when you get to it 18:29:13 I think that the most likely implication will be that other projects wind up expressing dependencies on keystone which will be captured as tags 18:29:15 bknudson, link? 18:29:50 geoffarnold: it's still a WIP so I think we will know more at the summit. 18:30:04 geoffarnold: but for the most part, not a lot will change for us. 18:30:13 gyee: https://review.openstack.org/#/c/153296/ is the other one 18:30:28 Agreed. I'd expect that it will be a topic for the midcycle, as we see how it ripples out across projects 18:30:36 geoffarnold, I heard some noise about nova cascading, cells, containers, etc which may be related to what you are doing 18:30:36 http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html 18:30:44 you may want to coordinate 18:30:52 gyee: doing endpoint enforcement via policy seems weird to me, i'm not sure about putting policy lines into oslo.config - and i'm not sure i see where you will ever want to match on more than endpoint/service _Id 18:31:07 I'm planning to raise it in cross-project with Thierry 18:31:22 ah, this govern. 18:31:32 bknudson, those look like spec and impl to me 18:31:32 "API services should support at least Keystone" -- looks like we're in! 18:31:50 bknudson, Bob's no longer working on OpenStack 18:31:52 ayoung: this is gyee's impl: https://review.openstack.org/#/c/177661/ 18:32:22 jamielennox, using oslo policy is much more flexible 18:32:23 gyee, would you have any problem using a policy.json style file as the way to specify what to enforce? 18:32:28 gyee: you are ruthless! 18:32:33 you can specify region, service_type, matches 18:32:37 you are doing policy type stuff already, just we want that enforcement on every call 18:33:00 gyee: region doesn't exist, and i don't see the point in service_type 18:33:03 ayoung, no need for file, just load the rule dynamically 18:33:13 gyee, load the rule dynamically from where 18:33:34 ayoung, from the specified rule 18:33:39 I see this as "enforce this policy on every call" 18:33:40 middleware needs to know what its endpoint is? 18:33:45 bknudson, yes 18:33:49 bknudson: yes. 18:33:51 how does it know? 18:33:53 config option? 18:33:59 bknudson, chicken and egg problem 18:34:01 bknudson, a rule 18:34:26 ayoung, I believe the chicken come first 18:34:40 so the rule has it hardcoded 18:34:44 or it could have the name? 18:34:51 jamielennox, region is in the endpoint 18:34:53 gyee, lets not hard code the logic here. 18:34:53 v3 catalog 18:35:08 load ap olicy file, but it does not need to be the same one as we ship globally 18:35:12 ayoung, no hardcoding 18:35:28 enforcing on region and service_type feels like your pulling the teeth out of the spec, it was all about knowing an actual id now we match on just anything 18:35:33 but lets enforce by oslo policy 18:35:40 so you need to define what's in the context and then just apply the rule 18:35:41 ayoung, it a rule,whether that's coming from policy.json or service conf, it makes no difference 18:35:41 sounds like this spec should be discussed as part of the dynamic policy discussions 18:35:42 seems easy enough 18:35:49 jamielennox, I see it more like "here is a policy rule enforced on every endpoint" 18:36:08 dstanek: agreed 18:36:12 dstanek, ++ 18:36:13 does the spec say what's in the context? 18:36:14 if region is in the token, we can enforce on it...or on other things e ahve not yet dreamed of 18:36:31 bknudson, yes, we basically flatten the endpoint and match it against the rule 18:36:33 this is getting into the dynamic policy world...I'm thrilled 18:36:38 if one endpoint match, we're good 18:36:46 what do you get from the token? 18:36:52 ayoung, fugyeah! 18:36:55 bknudson, service catalog 18:37:17 middleware needs to know the endpoint he is serving, since it will need to retrieve the policy for that specific service 18:37:19 oh, so the rule is just endpoint==as23sfsadf9223 18:37:29 bknudson, I got a change into oslo policy that allow "if anything in this list matches, treat it as True" 18:37:39 ayoung, you can reuse the code for your policy enforcement middleware later on 18:37:43 an added bonus :) 18:37:45 so if endpoing in service.endpoints.ids blah blah 18:38:15 that's all you need? seems like this is way more general than it needs to be. 18:38:31 more complex than it needs to be 18:38:35 bknudson, we need to match what we support for endpoint groups on the service side 18:38:44 ayoung: is your new agenda item the one labeled test script? 18:38:47 nor does it let you reuse that endpoint id for policy fetching because you'd have to try and parse it out from the policy line 18:38:55 but yes, I am give you a Toyota with a Ferri engine :) 18:39:23 dstanek, yes 18:39:29 ferrari engine 18:39:56 gyee: i need to read some of the other policy specs before i can formulate an intelligent opinion 18:40:20 right now i just see the want to churn on parts of the security model and i am hiding under my desk 18:40:47 The challenging part is going to be having that admin (not us developers) editing policy.json and verified that it worked. 18:40:54 there's a security model? 18:41:02 bknudson: lol. 18:41:06 security is a process, software is a tool 18:41:14 any more parting thought on the spec gyee brought up? i'd like to keep moving along since we can't solve this one today 18:41:37 dstanek, ++ agree let's move 18:41:57 dstanek, I'm bleeding on the specs now...we can move on 18:42:06 david8hu, have you ever seen the policy simulator in AWS? 18:42:24 david8hu, I really like that idea. 18:42:41 doesn't sound like we have any blueprints that we want to cover as far as needing a spec...moving on 18:42:44 #topic Test scripts 18:42:45 raildo, no. Love to see it. 18:42:50 ayoung: ... you have to floor 18:43:19 OK...so 18:43:21 dstanek: after ayoung I have a quick question for the group. 18:43:27 I've been trying to get my QA working up stream 18:43:33 and I think we all want this 18:43:58 the frist attempt was using the specs..but I think that is too static 18:44:12 what we need, I think, it a semi-forma doc that explains how to test a feature 18:44:18 the first hack should come from the dev 18:44:27 and the nthe QA folks can start from that, ask questions, and update 18:44:43 I think etherpad is the right tool 18:44:50 ayoung, by QA you mean tempest folks or your internal QA? 18:44:55 I wrote a handful for current folks 18:45:10 gyee, ionternal or external, but not necessarily tempest 18:45:19 maybe more like, before we get a functional test written 18:45:30 ayoung: what kinds of tests are you thinking? 18:45:35 this way, we can communicate what to test, and then a QA engineer can code from that 18:45:39 dstanek, examples: 18:45:50 https://etherpad.openstack.org/p/keystone-token-scoping 18:45:56 https://etherpad.openstack.org/p/hierarchical-projects 18:45:57 if the tests aren't automated then they're useless. 18:46:01 i know that QA needs some help - doesn't this have a likely impact that 5 companies QA teams are all running the same set of scripts and calling it done 18:46:07 the other ones I am looking at are for 18:46:11 bknudson, this is before that 18:46:19 bknudson, someone has to write the automated tests 18:46:36 whoever develops the feature writes the tests 18:46:36 before they can write it, they need to know what to test 18:46:39 and the documentation 18:46:40 bknudson, no 18:46:48 that is too risky 18:46:51 i mean if we can write an automated test script then it should be in tempest 18:46:57 whoever writes the feature explains how to test tit 18:47:01 I think this work should go together with functional tests 18:47:06 the QA engineers know how to write and break things 18:47:17 these are basically tempest tests or should be right? 18:47:18 QA engineers can come in later and fix the tests 18:47:24 jamielennox, actually not in tempest, but rather in our function test repo, 18:47:28 or comment on the review 18:47:46 we only test in production 18:47:51 ayoung: it can't be in our functional tests because you tests scripts use other services 18:47:55 bknudson: I agree that at least first pass on tests needs to come from the developer 18:48:02 ayoung, so I think you should sync with dstanek to figure out how the functional tests environemnt will look like, 18:48:07 dstanek, some might, some might be keystone only 18:48:10 and then we'll have minimal effort to adopt them 18:48:20 depends...but we should still descirobe how to test, at least positive sting first 18:48:28 ayoung: functional tests are keystone only. Integration is tempest. 18:48:41 ayoung: if it uses another service it's likely the latter. 18:48:44 if you're looking to break things then positive tests aren't going to tell you much 18:48:51 morganfainberg, and tempest is its own project and workflow and we'll get thing in there eventually, too 18:49:00 ayoung: the functional tests should really be keystone only and x-project stuff belongs in tempest 18:49:00 I think deciding where to run the tests needs to be part of the test design 18:49:26 dstanek: agreed. Functional is not x-project. 18:49:32 we've had a harder time in keystone since we've got so many backends / configs 18:49:33 but I think the "here is how you test it" conversation needs to come first 18:49:33 we can and should talk more about this at the summit 18:49:40 and that is what I am tryuing to start 18:49:51 I guess other projects have a similar issue. 18:49:53 morganfainberg, it should be integration tests (considering the whole openstack), right 18:49:58 but then they push the CI off to other groups. 18:50:00 dstanek: ++. Maybe this is the last work session? 18:50:07 then, we can try and get our companies internal QA folks to start working upstream...for those that are not trying to special-sauce their qa 18:50:11 morganfainberg: that would work for me 18:50:39 Ok. I'll setup the last work session as testing. He last fishbowl I'm still mulling over. 18:50:44 so...do you agree that before we automate, we need to design tests 18:50:46 this is what's stopping internal qa folks from working upstream? 18:50:50 S/he/the 18:51:09 bknudson, I'd say so 18:51:14 we should also get some of our QA people in there if any are attending the summit 18:51:26 so...here is what I propose 18:51:36 we set up an etherpad area for functional tests 18:51:43 and we neame the appropriately 18:51:52 dstanek: I'll cross track the session with qa as well. 18:52:17 as we get stuff done, some of which is cross project (WebSSO) we start documenting there how to test 18:52:38 WebSSO would be tempest 18:52:45 we can link to it from the blueprint 18:52:50 Is an etherpad permanent enough/ Or is this temporary docs? 18:52:54 #action morganfainberg will add the session for function/integration testing and add qa 18:52:59 gyee, eventually, but don't get too ambitious 18:53:12 does tempest have a way to drive a browser? 18:53:17 don't try to boil the ocean with this. 18:53:21 topol: ether pad is permanent enough for a start. Longer term wiki. 18:53:30 bknudson, selenium ? 18:53:37 morganfainberg +++ Good answer!! 18:53:49 morganfainberg, so...can we have, something like https://etherpad.openstack.org/p/keystone/testscripts/hierarchical-projects 18:53:55 ayoung: so you just want a place to put tests scripts so that someone from a qa team can implement? 18:54:00 topol: so post summit we can move to wiki. 18:54:02 dstanek, more than just implement 18:54:06 sounds like a bug use of a bug 18:54:10 bknudson, mechanize 18:54:15 s/a bug/a good/ 18:54:25 I want them to be able to update as they learng things, and also record issues they had "how do I create a project with a parent" 18:54:51 it might be multiple test scripts eventually, but to start, just document the process 18:55:01 it might feed into a howto guide as well 18:55:07 ayoung: wouldn't that be part of the test script itself? 18:55:13 ayoung: longer term wiki is more correct but we can start with an ether pad. 18:55:17 dstanek, can't for complex features 18:55:44 i just want my gherkin back 18:56:03 ok, so i think that ayoung should start the page and we can discuss more at the summit or offline 18:56:08 sound good? 18:56:10 ++ 18:56:12 morganfainberg, it needs to be a conversation, especially early one, when we are just sussing out a feature. Once we have it static...it should be in code. Wiki...I wouldn;'t say no 18:56:22 3 minutes left 18:56:22 dstanek: after ayoung I have a quick question for the group. 18:56:33 So one item from me: as many of you know I can't attend the summit this year (I'm moving house the weekend before the summit)..so I'll miss the fun...but will try and keep track where I can remotely. 18:56:34 Yep. 18:56:44 #topic morganfainberg's question 18:56:45 henrynash: I'll miss you 18:56:48 henrynash: gonna miss you there! 18:56:49 henrynash, will we see you at the midcycle? 18:57:01 ayoung: ABSO…BLOODY…LUTELY 18:57:02 henrynash: we'll record the cartwheel 18:57:05 So. Do we want a meeting next week or just open time for people to prep for summit? 18:57:19 bknudson: relying on it 18:57:22 did henrynash mention where the new homestead is? 18:57:27 We are already skipping week of the summit and the one post 18:57:34 morganfainberg, maybe we can have a quick one 18:57:36 Let's have the meeting planned 18:57:43 morganfainberg, and end it earlier if we havent enough items 18:57:45 topol: by the sea near Bristol…midcyle meetup one day there? 18:57:48 * topol He's not suffering :-) 18:57:48 If nothing else, there will be summit stuff to hammer out 18:57:51 morganfainberg: a quick touch point meeting wouldn't hurt 18:57:54 there seems to be a lot of not much going on in the run-up to the summit 18:58:14 dstanek: ok I'll keep the meeting. We will just say "hi" summit 18:58:24 what are we going to do when there's no summit to put stuff off until? 18:58:27 And then move on unless something comes up. 18:58:32 we should make an effort not to bring up things that we can/should discuss at the summit other than to let other know there's something to discuss 18:58:39 dstanek: ++ 18:59:14 parting thoughts? 18:59:19 henrynash: bristol connecticut? 18:59:21 Have a good week! 18:59:38 * morganfainberg goes to get food. 18:59:41 bknudson: didn’t know there was one! 19:00:10 henrynash: they have whole europe there.... 19:00:15 #action ayoung to blaze a path for test documentation 19:00:22 ok, that's all she wrote 19:00:27 #endmeeting