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