18:02:13 <morganfainberg> #startmeeting keystone
18:02:13 <openstack> Meeting started Tue Apr 28 18:02:13 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:17 <openstack> The meeting name has been set to 'keystone'
18:02:19 <morganfainberg> Hi everyone!
18:02:20 <henrynash> answer: spring cabbage
18:02:25 <hogepodge> o/
18:02:30 <morganfainberg> welcome to "it's almost summit time" edition of the Keystone meeting
18:02:34 <geoffarnold> Greetings
18:02:34 <ayoung> BURMA!
18:02:44 <morganfainberg> #topic rollcall
18:02:44 <ayoung> Sorry, I panicked
18:02:51 <ayoung> ROBOT ROLL CALL!
18:02:58 <morganfainberg> #vote Rollcall! here
18:03:00 <bknudson> tom servo
18:03:02 <lbragstad> o/
18:03:03 <rharwood> #vote pedro
18:03:04 <henrynash> #votre here
18:03:08 <morganfainberg> #startvote Rollcall! here
18:03:10 <openstack> Unable to parse vote topic and options.
18:03:11 <stevemar> #vote here
18:03:12 <marekd> #vote here
18:03:14 <morganfainberg> #startvote Rollcall? here
18:03:15 <openstack> Begin voting on: Rollcall? Valid vote options are here.
18:03:16 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:03:17 <raildo> #vote here
18:03:17 <rharwood> #vote here
18:03:18 <david8hu> #vote here
18:03:19 <dstanek> #vote here, there, everywhere
18:03:19 <morganfainberg> #vote here
18:03:19 <geoffarnold> #vote here
18:03:19 <openstack> dstanek: here, there, everywhere is not a valid option. Valid options are here.
18:03:21 <stevemar> #vote here
18:03:22 <rodrigods> #vote here
18:03:24 <gyee> #vote here
18:03:25 <marekd> #vote here
18:03:26 <henrynash> #vote here
18:03:28 <roxanaghe> #vote here
18:03:28 <ayoung> #vote here\
18:03:28 <openstack> ayoung: here\ is not a valid option. Valid options are here.
18:03:29 <stevemar> #vote pedro
18:03:30 <ayoung> #vote here
18:03:31 <openstack> stevemar: pedro is not a valid option. Valid options are here.
18:03:35 <amakarov> #vote here
18:03:39 <dstanek> openstack: valid options are where?
18:03:39 <stevemar> #vote for stevemar!
18:03:39 <ayoung> #vote here
18:03:39 <openstack> stevemar: for stevemar! is not a valid option. Valid options are here.
18:03:40 <ayoung> #vote here
18:03:42 <ayoung> #vote here
18:03:43 <ayoung> #vote here
18:03:44 <ayoung> #vote here
18:03:49 <morganfainberg> This is the last rollcall
18:04:01 <morganfainberg> i will be unioning the last 3 meetings roll calls
18:04:04 <morganfainberg> and updating the list
18:04:06 <morganfainberg> fyi
18:04:06 <lbragstad> #vote here
18:04:11 <gyee> ayoung, voter fraud
18:04:12 <dstanek> then the room self destructs and we forget this ever happened
18:04:15 <ayoung> #vote here
18:04:22 <morganfainberg> dstanek: what ever happened?
18:04:23 <dolphm> #vote here
18:04:32 <morganfainberg> 20s more
18:04:42 <henrynash> (them tune to mission impossible starts playing)
18:04:42 <samueldmq> #vote here
18:04:56 <morganfainberg> your mission should you choose to accept it...
18:05:04 <lhcheng> #vote here
18:05:15 <morganfainberg> #endvote
18:05:16 <openstack> Voted on "Rollcall?" Results are
18:05:17 <openstack> here (17): rodrigods, gyee, lbragstad, ayoung, morganfainberg, lhcheng, marekd, geoffarnold, david8hu, dolphm, samueldmq, amakarov, henrynash, roxanaghe, rharwood, raildo, stevemar
18:05:17 <ayoung> #vote here
18:05:19 <jamielennox> #vote here
18:05:23 <jamielennox> aww
18:05:26 <morganfainberg> jamielennox: saw it. no worries
18:05:28 <henrynash> slackers
18:05:31 <stevemar> jamielennox, always missing out
18:05:35 <ayoung> HA!
18:05:46 <morganfainberg> ok going to do things a bit out of order today
18:05:51 <morganfainberg> so we can get the easy stuff done first
18:05:51 <jamielennox> always miss the first couple of minutes..
18:06:01 <morganfainberg> #topic Midcycle update
18:06:03 <morganfainberg> ayoung: o/
18:06:07 <bknudson> skip the snooze alarm
18:06:16 <ayoung> OK...Midcycle
18:06:34 <morganfainberg> #action morganfainberg to send midcycle info email this week
18:06:35 <ayoung> I've been talking with Orran Kreiger of the Mass.  Open CLoud effort, HQed at Boston University.
18:06:56 <ayoung> Since it is summer session, there should be ample space available.
18:07:11 <morganfainberg> great.
18:07:17 <ayoung> We're trying to lock down where exactly that is, but suffice to say, BU should be a GO  for the Midcycle
18:07:25 <morganfainberg> which dates?
18:07:33 <dolphm> BU?
18:07:36 * bknudson books travel
18:07:38 <dstanek> dates and hotel info is important
18:07:39 <ayoung> There are even Dorm rooms available if people want, at $75 / night
18:07:42 <marekd> Boston university i guess
18:07:43 <david8hu> @ayoung Dorm rooms will be available as well for keystoners?
18:07:43 <dolphm> boston U?
18:07:48 <dstanek> dolphm: yes
18:07:57 <gyee> co-ed?
18:07:59 <samueldmq> dolphm, Boston University
18:08:01 * geoffarnold plans to spend a few days with family
18:08:13 <morganfainberg> ayoung: Jul 15-17?
18:08:25 <ayoung> Yes.  that is the preferred dates
18:08:35 <morganfainberg> ayoung: ok we will plan for 15-17
18:08:56 <morganfainberg> #info Keystone midcycle, July 15-17 at Boston University
18:09:11 <henrynash> Henry confirms hs is definitely, categorically, not moving house then
18:09:17 <morganfainberg> #action ayoung to look into RedHat sponsorship of food etc.
18:09:22 <ayoung> Parking is $8/day, and if overnight parking is needed I believe that is $24/day.
18:09:28 <morganfainberg> #action morganfainberg to look into HP sponsorship of food etc
18:09:46 <bknudson> baked beans
18:09:56 <david8hu> ayoung: AAA discount for overnight stay in the dorm room?
18:10:09 <ayoung> There might be better hotel options per COmapny, if your company has a presense in the area.  If so, please find out and share
18:10:31 <morganfainberg> I'll be looking into hotel blocks
18:10:33 <morganfainberg> etc
18:10:40 <morganfainberg> but that can wait a week or two
18:10:45 <morganfainberg> or until the summit
18:11:03 <bknudson> let's not spend the whole summit talking about the mid-cycle.
18:11:22 <ayoung> There is a really nice room in the Photonics building, but it is not available until the 28th.  I don't think we want to wait on that, right?
18:11:30 <ayoung> July 27-29
18:11:32 <morganfainberg> bknudson: the goal is to do what we mostly do at the midcycle at the summit
18:11:50 <morganfainberg> bknudson: specifics about what will happen at the midcycle will be discussed *post* summit (e.g. goals/targets/etc)
18:12:27 <ayoung> morganfainberg, just to firm up; I asked them to target a space for 30 people
18:12:32 <morganfainberg> ayoung: perfect
18:12:33 <ayoung> is that too high or too low?
18:12:40 <morganfainberg> ayoung: we will keep it at max 30
18:12:45 <bknudson> I invited dhellmann to the meetup since he hasn't been to any.
18:12:47 <morganfainberg> i think 20-25 has been the numbers the last couple times
18:12:56 <morganfainberg> but 30 is our hard cap.
18:13:03 <morganfainberg> ok lets keep moving
18:13:05 <ayoung> OK.  I think, then, we can  probably even make use of a standard classroom.  Should give us more options
18:13:10 <morganfainberg> #topic For stevedore, should I assume no extensions?
18:13:12 <morganfainberg> bknudson: o/
18:13:30 <bknudson> so just a question on whether the stevedore should assume that extensions are there or not.
18:13:39 <morganfainberg> bknudson: i would drop the "Extension" part
18:13:41 <bknudson> i.e., should I have "contrib" in the endpoint names.
18:13:44 <gyee> shouldn't they be discoverable?
18:13:46 <morganfainberg> i like the keystone.X
18:13:49 <gyee> extensions I mean
18:13:51 <morganfainberg> not keystone.contrib.x
18:14:13 <bknudson> otherwise whoever does the final work for removing extensions will have to update the entrypoints
18:14:16 <morganfainberg> bknudson: hopefully we will see continued progress on dropping extensions into core this cycle.
18:14:26 <morganfainberg> bknudson: lets just drop contrib now.
18:14:32 <morganfainberg> unless someone is opposed to that
18:14:33 <bknudson> so if people agree I'll just drop the contrib.
18:14:46 <bknudson> I'm not opposed.
18:14:53 <jamielennox> i don't mind, it's not hard either way
18:15:02 <samueldmq> vote ?
18:15:16 <stevemar> i'd like to see contrib go away
18:15:18 <gyee> drop contrib from where, request PATH?
18:15:19 <morganfainberg> samueldmq: just say if you're opposed to dropping .contrib. from the entrypoint name
18:15:33 <jamielennox> gyee: it's the stevedore namespace for finding the driver
18:15:41 <morganfainberg> gyee: for stevedore loading, the entrypoint name should be Keystone.X or Keystone.contrib.X ?
18:15:50 <stevemar> bknudson, tell dhellmann to organize an oslo meetup :P
18:16:00 <gyee> oh that, should be fine
18:16:08 <morganfainberg> going once.
18:16:10 <dhellmann> stevemar: that's dims' problem now
18:16:12 <samueldmq> morganfainberg, no I am not :)
18:16:15 <morganfainberg> twice
18:16:32 <morganfainberg> ok bknudson, dropping .contrib. now is the course
18:16:35 <morganfainberg> vs. later
18:16:41 <bknudson> ok, thanks
18:16:45 <dhellmann> I would include "keystone" in the entry point namespace, but not in the name of each entry point, fwiw
18:17:00 <morganfainberg> dhellmann: the namespace yes
18:17:03 <dhellmann> k
18:17:08 <gyee> shouldn't be any backward compat concern right?
18:17:27 <morganfainberg> #info stevedore loading of extension/backends will not include '.contrib.' in the namespace
18:17:39 <morganfainberg> #topic Release Notes (Kilo)
18:17:44 <morganfainberg> RC2 is kilo
18:17:48 <jamielennox> and please review the change that moves the first ext into core
18:17:51 <morganfainberg> it will be released on thursday
18:17:58 <dhellmann> gyee: what we did in some other projects early on was register the old importable name as a duplicate plugin name (so "kombu" and "oslo.messaging.drivers.impl_kombu" pointed to the same thing)
18:18:10 <amakarov> so we'll have all batteries right under keystone. ?
18:18:27 <morganfainberg> #link https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Identity_.28Keystone.29
18:18:31 <amakarov> won't it be a bit messy?
18:18:33 <morganfainberg> please look at it.
18:18:46 <morganfainberg> amakarov: this is specifically about .contrib. code
18:18:56 <morganfainberg> amakarov: which is being moved into core already
18:18:57 <gyee> dhellmann, so we'll need to use the same trick?
18:19:04 <morganfainberg> amakarov: so it would require a change later
18:19:16 <morganfainberg> gyee: bknudson is already handling those cases
18:19:27 <gyee> excellent
18:19:30 <morganfainberg> so
18:19:32 <morganfainberg> release notes
18:19:34 <jamielennox> gyee: we were just doing if you don't find it in stevedore fallback to the old way
18:19:38 <bknudson> the import code just falls back to the old method if stevedore didn't work.
18:19:43 <morganfainberg> the release notes need to be done by EOD tomorrow
18:20:10 <morganfainberg> I need someone willing to take on working on release notes
18:20:17 <morganfainberg> I am going to be offline all tomorrow
18:20:33 <morganfainberg> I will be doing some further work today. but i don't think it will be complete
18:20:41 <morganfainberg> everyone should feel free to edit them.
18:20:56 <morganfainberg> but i need a specific person delegated the job of "ensuring they are spot on"
18:20:58 <samueldmq> morganfainberg, is that just to detail those points
18:21:02 <morganfainberg> and you'll talk w/ ttx tomorrow
18:21:10 <morganfainberg> to confirm everything is on track
18:21:21 <morganfainberg> samueldmq: it's making sure the notes are complete
18:21:34 * dolphm volunteers
18:21:36 <samueldmq> morganfainberg, I can do if you want me to
18:21:38 <morganfainberg> dolphm: yay!
18:21:45 <morganfainberg> samueldmq: work with dolph
18:21:52 <samueldmq> ++
18:22:07 <morganfainberg> #action dolphm and samueldmq to confirm release notes are complete for Kilo by EOD Wednesday
18:22:30 <morganfainberg> ok moving on to summit and liberty planning
18:23:04 <morganfainberg> going to spend ½ the rest of the meeting on liberty priorities thne we will switch to summit planning so we can assign slots for session topics
18:23:10 <morganfainberg> #topic Liberty Priorities
18:23:20 <morganfainberg> #link https://etherpad.openstack.org/p/keystone-liberty-priority-specs
18:23:36 <morganfainberg> So. It's that time. what are we wanting to focus on for Liberty?
18:23:46 <morganfainberg> these aren't written in stone
18:23:53 <morganfainberg> just the first pass of priorities
18:24:33 <gyee> Give me Liberty, or give me money back!
18:25:02 <amakarov> I'd like to see functional testing implemented
18:25:03 <marekd> I might have some objectives regarding intercloud stuff, but that needs some more in depth discussions probably over the summit.
18:25:11 <marekd> amakarov: ++
18:25:13 <ayoung> Dual Scoped Token again?
18:25:26 <morganfainberg> marekd: intercloud stuff is worth a summit session for sure
18:25:40 <bknudson> I'm planning on just reviewing stuff as it comes up.
18:25:52 <stevemar> bknudson, no big features?
18:26:04 <marekd> morganfainberg: i am not proposing anything for liberty know because as you know i don't have anything very detailed. I am really counting on some brainstorming with you in 3 weeks.
18:26:06 <stevemar> (from you)
18:26:14 <morganfainberg> marekd: sure.
18:26:27 <bknudson> My employer doesn't give me time to implement any features.
18:26:36 <marekd> stevemar: reviews from bknudson are big feature itself.
18:26:37 <raildo> ayoung, we have a spec for this https://review.openstack.org/#/c/176054/3/specs/liberty/dual-scoped-token.rst,  I believe that we don't need to discuss in summit, but we want to implement this on liberty:
18:26:39 <dstanek> amakarov: we need some volunteers to start writing tests
18:26:43 <stevemar> marekd, true
18:27:16 <amakarov> dstanek, myself and I'll try to talk bbobrov into it :)
18:27:43 <marekd> dstanek: there was some trials with federation setup/tests so, as long this is not done i can probably help with federation part of the functional tests.
18:27:48 <morganfainberg> so the way I'm seeing it now:
18:27:54 <ayoung> raildo, probably not
18:28:09 <ayoung> but let me read up first
18:28:11 <dstanek> marekd: you're going to be at the summit right?
18:28:17 <marekd> dstanek: yes!
18:28:26 <morganfainberg> Features that look like they are a priority (API impacting): Policy, ???, ???, ???, Domain SQL enhancements
18:28:27 <dstanek> marekd: we should work together to get all the federation stuff done
18:28:34 <ayoung> dula scope is confusing,
18:28:40 <dstanek> just added Python3 to the list
18:28:47 <morganfainberg> oh and one of those ??? is reseller
18:28:52 <ayoung> but...the bones of the idea are solid
18:29:06 <ayoung> raildo, my only issue is with what we are calling it
18:29:17 <marekd> dstanek: as much as time lets us do this.
18:29:19 <morganfainberg> so I'm ok with solving the other priorities at the summit for API impacting
18:29:23 <ayoung> dual scoped is going to think people want one token for two projects.
18:29:24 <bknudson> if marekd isn't there, a poster of him will be.
18:29:27 <gyee> ayoung, polymorphism
18:29:28 <ayoung> And people have asked for that
18:29:41 <amakarov> As we deprecate LDAP assignment backend we need to start hardening SQL backend to support multi-master environments
18:29:43 <ayoung> gyee, just polyps actually
18:29:43 <morganfainberg> with the caveat that specs are proposed to the backlog before we all fly to vancouver
18:29:57 <henrynash> ayoung: maybe we don’t need to call it anything…it’s just teh token you get on a project this is alos acting as a domain?
18:30:03 <ayoung> henrynash, ++
18:30:07 <amakarov> For ex. ensure we don't use autoincrement
18:30:13 <ayoung> henrynash, 100%
18:30:20 <raildo> ayoung, yes... we are improving it. the dual scoped token is for just one entity that behaviour as project and a domain.
18:30:22 <morganfainberg> henrynash: we probably need to support domain in the scope if it doesn't break anything
18:30:24 <raildo> henrynash, ++
18:30:26 <morganfainberg> but easy to do that.
18:30:30 <gyee> call it the "magik token"
18:30:31 <stevemar> morganfainberg, what about splitting up keystone?
18:30:37 <marekd> stevemar: microservices?
18:30:43 <morganfainberg> stevemar: is that a realistic target for liberty
18:30:49 <henrynash> morganfainberg: yep…if you explictly ask for domain scope…that’s all you get
18:30:54 <stevemar> morganfainberg, hmm... maybe not
18:31:13 <rodrigods> gyee, magic token hahah
18:31:14 <morganfainberg> i'm inclined to say we would need to focus on auth shuffling and/or a conductor like interface to identity store if we want that
18:31:15 <dstanek> we should at least remove the circular deps is any still exist
18:31:20 <amakarov> stevemar, we'll need a ton of TNT to explode it :)
18:31:21 <morganfainberg> but a real split... i don't think will happen
18:31:23 <ayoung> stevemar, I think so
18:31:40 <ayoung> stevemar, identity can be split off, as can policy, leaving assignment in the middle
18:31:47 <gyee> morganfainberg, ++ for conductor
18:31:58 <gyee> that one's very useful
18:31:58 <marekd> gyee: morganfainberg what's conductor?
18:32:19 <stevemar> i think it's worth a chat, but maybe not realistic for L
18:32:20 <gyee> marekd, layers between core and drivers
18:32:24 <gyee> layer
18:32:58 <ayoung> stevemar, specifcially, we idenitfy new service types:  identity is the good name, but really should be the user and group operations.  token ops happen on Keystone assignmnet service.  Policy is its own service.  Maybe catalog, too
18:33:06 <dstanek> we needs to fix the layers we already have. especially isolating web stuff from the rest of the system
18:33:06 <jamielennox> but conductor for nova is a separate application - i don't see us needing that for keystone
18:33:07 <amakarov> gyee, is there a spec for conductor?
18:33:10 <ayoung> stevemar, we start the ball rolling
18:33:12 <morganfainberg> for non-API impacting (aka not "features"), I see priorities being (in this order): stevedore for drivers, Functional Testing, Stable KSDI (driver interfaces) [yes this is personal bias], Fix Dependency Injection (no circular deps), Pecan, python3, v3-only
18:33:17 <ayoung> but assume that all these things are running in one server
18:33:22 <geoffarnold> http://docs.openstack.org/havana/config-reference/content/section_conductor.html
18:33:24 <gyee> marekd, we can essentially does orchestration workflow in there
18:33:39 <ayoung> just to get the service catalog straight, and fix the client.
18:33:52 <marekd> geoffarnold: thanks.
18:33:55 <amakarov> morganfainberg, v2.0 will be dropped?
18:34:09 <morganfainberg> amakarov: deprecated officially if openstack works with v2 turned off
18:34:18 <dstanek> conductor sounds like architecture envy - seems overly complicated for this cycle
18:34:43 <morganfainberg> dstanek: agreed. it's too much.
18:34:48 <amakarov> dstanek, ++
18:35:01 <jamielennox> overly complicated in general for us
18:35:05 <bknudson> the priorities mentioned by morganfainberg look good to me.
18:35:07 <ayoung> we dopn't need conductor
18:35:13 <geoffarnold> Conductor is most important for large scale in-service updates, so that mixed version configs will work
18:35:19 <ayoung> they need it for thngs that are NOT the API service talking to the DB\
18:35:28 <morganfainberg> if we split off identity into it's own API conductor might be required
18:35:40 <morganfainberg> it's own micro-service thing
18:35:44 <geoffarnold> I don't see that we need it
18:35:50 <ayoung> morganfainberg, I don't think so  ...different architecture
18:35:51 <morganfainberg> it's a long term goal
18:35:56 <morganfainberg> anyway
18:36:06 <jamielennox> morganfainberg: we shouldn't, identity would just manage it's own db
18:36:24 <morganfainberg> jamielennox: how does assignment ask identity for user-information then? or are we pure federated?
18:36:30 <bknudson> are there specs or blueprints for everything on the priority list?
18:36:46 <ayoung> even if Identity "wrote" to the user table and tokens read from the user table, they can still share a DB instance for that and get things optimized
18:36:52 <morganfainberg> bknudson: the Stable KSDI, and python 3 has specs proposed to backlog
18:37:08 <ayoung> the one par to API V3 we should look at sp[litting off in liberty is policy
18:37:09 <jamielennox> morganfainberg: sure there's some for of request/response there but why couldn't that just be the public identity API
18:37:14 <morganfainberg> bknudson: dependency fix is backlog iirc already, v3 only isn't a spec [it's cross-project devstack-y stuff]
18:37:25 <bknudson> do we also have middleware and client priorities?
18:37:28 <morganfainberg> bknudson, pecan is maybe a spec?
18:37:57 <morganfainberg> bknudson: middleware is going to release like the server, but i think it's not going to grow a lot of new features/capabilities
18:37:58 <jamielennox> do we want a spec for pecan? that review's so old i hadn't considered it
18:38:03 <morganfainberg> jamielennox: yes please
18:38:06 <geoffarnold> For Liberty, I'm assuming that once all of the other projects have figured out what they need to do in order to support hierarchical multitenancy, we may get a few small change requests. Good to close out most of that during the summit
18:38:19 <ayoung> geoffarnold, ++
18:38:19 <morganfainberg> ok let me re-iterate priorities:
18:38:24 <bknudson> I'd like bp/auth-token-use-client to be a priority, since it was approved in K timeframe but didn't make it.
18:38:31 <rodrigods> geoffarnold, ++
18:38:48 <ayoung> middleware's big thing is going to be tokenless
18:39:08 <ayoung> and...we need to make sure we make that work for X509, but also Kerberos and Basic Auth
18:39:24 <jamielennox> bknudson: sure, the other thing i want to do for middleware is the bp/request-helpers and doing X-Service-Token automatically
18:39:27 <morganfainberg> API Impacting: Reseller(Has Spec, Approved), Domain SQL Enhancements (Needs spec?), Policy(Has spec, which specs?), TBD@Summit, TBD@summit
18:39:44 <morganfainberg> anyone have anything to add to that^
18:39:57 <bknudson> how about getting rid of extensions?
18:40:00 <morganfainberg> bknudson: sure that BP should be non-api impacting
18:40:06 <gyee> ayoung, the bit and pieces are in place to support Kerberos and Basic Auth
18:40:07 <morganfainberg> bknudson: i'll add that to the non-api impacting list.
18:40:09 <bknudson> really?
18:40:17 <morganfainberg> bknudson: the middleware one
18:40:25 <morganfainberg> bknudson: was the non-api impacting
18:40:37 <morganfainberg> bknudson: sorry was slow typing.
18:41:12 <bknudson> I'm now suggesting getting rid of extensions as API impacting.
18:41:24 <ayoung> gyee, yes...on the server side.  Just want to make sure the middleware gets what it needs, too
18:41:27 <morganfainberg> ok we have 2 open priorities: tokenless-auth/operations one of them? or decide at summit? and rid of extensions is the other proposal
18:41:42 <bknudson> I'd like to see tokenless-auth on the list.
18:41:47 <morganfainberg> ok
18:41:47 <ayoung> tokenless-auth/operations  should be there
18:41:51 <gyee> morganfainberg, tokenless-auth has already decided
18:41:56 <gyee> we just need to get the impl in
18:42:11 <morganfainberg> API Impacting: Reseller(Has Spec, Approved), Domain SQL Enhancements (Needs spec?), Policy(Has spec, which specs?), Tokenless-auth(Has Spec, not approved),  TBD@summit
18:42:14 <ayoung> its close, last I saw
18:42:20 <jamielennox> gyee: and figure out how tokenless-auth is going to impact X-Service-Tokens
18:42:29 <morganfainberg> bknudson: i'd be ok with adding "no-more extensions"
18:42:43 <morganfainberg> bknudson: if someone is signing up to do the work/spec
18:42:52 <gyee> jamielennox, not yet, still losing hair over that one
18:42:55 <henrynash> morgainfainberg: I’ll have a speci for the Domain SQL Enhancements ready before the summit
18:43:00 <morganfainberg> henrynash: ok
18:43:05 <ayoung> morganfainberg, lets say dynamic-policy for now, and decide at the summit how far we are willing to commit to on that
18:43:11 <morganfainberg> ayoung: ok
18:43:12 <stevemar> tokenless-auth (has code)
18:43:26 <morganfainberg> ayoung: just remember API impacting code freeze is liberty
18:43:27 <morganfainberg> 2
18:43:30 <ayoung> morganfainberg, I think we can cover that whole spec,
18:43:32 <morganfainberg> ok
18:43:55 <david8hu> ayoung, I signed up to help with dynamic policy.  Do not forget about me :)
18:44:00 <gyee> stevemar, https://review.openstack.org/#/c/156870/
18:44:08 <morganfainberg> ok lets leave the last slot open for TBD@summit
18:44:15 <gyee> only thing missing in that patch is to support ephemeral user
18:44:15 <ayoung> david8hu, you and samueldmq are going to become good friends
18:44:22 <stevemar> gyee, yep, i know - i've been reviewing it :P
18:44:23 <morganfainberg> we cna slot in extensions-no-more if we don't have something else to fill it
18:44:30 <samueldmq> ayoung, hi - reading up
18:44:35 <stevemar> morganfainberg, that's not user facing though
18:44:40 <stevemar> well, it sort of is
18:44:40 <ayoung> morganfainberg, K2K client extensions?
18:44:44 <david8hu> ayoung, we should have Philz coffee together ;)
18:44:55 <marekd> ayoung: that could include what i will probably want to wark
18:44:57 <marekd> work
18:44:58 <ayoung> We need a smarter client approach if K2K is going to be part of it.
18:44:58 <marekd> on
18:45:06 <ayoung> marekd, cool
18:45:09 <marekd> morganfainberg: ^^
18:45:09 <rodrigods> ayoung, K2K client plugin is under review
18:45:26 <rodrigods> and waiting for suggestions in its design
18:45:28 <stevemar> ayoung, there are a few bits of code around that are for k2k
18:45:39 * dims peeks
18:45:46 <stevemar> and we have a guy internally looking to add k2k support for horizon
18:45:47 <ayoung> rodrigods, its more than just an auth plugin.  It needs to be smart about chosing "where to go" and I will wave my hands and dance and things
18:45:52 <samueldmq> ayoung, ++ david8hu we can sync up later, I can work together in the specs (cleaning, etc0
18:45:56 <gyee> K2K is a workflow, just like aggregator
18:45:58 <morganfainberg> #info Liberty Priorities (API Impacting): Reseller(Approved Spec), Domain SQL Enhancements(Spec will be prior to summit), Dynamic-Policy(Clear Spec proposed before summit, Scope TBD @ summit), Tokenless-auth (Has Spec, needs approval, code ready), TBD@summit
18:46:08 <ayoung> so..is this a good lead in to the policy discussion morganfainberg ?
18:46:16 <rodrigods> ayoung, exactly, just called plugin because it was the first term
18:46:20 <morganfainberg> ayoung: going to finish the non-api list
18:46:20 <bknudson> those priorities look good to me.
18:46:23 <samleon> stevemar, that's great, thanks for that
18:46:24 <ayoung> k
18:46:28 <morganfainberg> ayoung: then we will slip over to policy
18:46:29 <ayoung> 15 minutes left
18:46:33 <morganfainberg> then do summit planning in -keystone channel
18:46:53 <morganfainberg> re-iterating non-API impacting priorities
18:47:39 <david8hu> samueldmq, we are going to have so much fun
18:47:46 <marekd> lol
18:47:50 <samueldmq> david8hu, ++
18:48:18 <morganfainberg> stevedore for drivers(Approved, No-spec), Functional Testing (has spec?), Stable KSDI (has spec, against backlog), Fix Dependency Injection (has spec?), Pecan (needs spec?), python3 (has spec, backlog), v3-only (no keystone spec needed), keystonemiddleware-uses-auth-plugins(code-ready, has spec, approved)
18:48:19 <samueldmq> marekd, hehe lol
18:48:25 <morganfainberg> am i missing anything from that list?
18:48:34 <morganfainberg> or did i add anything that shouldn't be there?
18:48:34 <lbragstad> token provider cleanup?
18:48:39 <morganfainberg> lbragstad: ah yes
18:48:43 <lbragstad> or is that in a different category?
18:48:43 <gyee> ABI?
18:48:49 <morganfainberg> gyee: Stable KSDI
18:48:51 <morganfainberg> gyee: it's there
18:48:53 <gyee> ah
18:48:57 <marekd> ayoung: for the 'smarter client approach for k2k' i think we will have to stick with token-per-cloud for now.
18:49:06 <morganfainberg> marekd: yes
18:49:08 <marekd> ayoung: and teach ksc to handle multiple tokens
18:49:13 <ayoung> marekd, that is fine.  Questions is "when to get the token"
18:49:18 <bknudson> I'm fine with those priorities.
18:49:23 <lbragstad> me too
18:49:28 <morganfainberg> anyone want to add more to the list/take things off?
18:49:34 <gyee> marekd, yes, don't think you want to share the fernet key :)
18:49:38 <morganfainberg> i will need some people to step up for taking on some of the work.
18:49:44 <morganfainberg> and we will need specs.
18:49:44 <bknudson> I don't understand the need for pecan.
18:49:56 <morganfainberg> bknudson: it's a swap of the route framework.
18:49:56 <marekd> morganfainberg: so, this intercloud thing?
18:50:02 <ayoung> morganfainberg, we are just starting to see Federation take off.  I'd like to leave some wiggle room in there for features we find neceesarty to make federation usable
18:50:11 <marekd> morganfainberg: unless you say no to add it here until summit
18:50:13 <ayoung> like...delegating the mapping rules to non-admin users
18:50:14 <gyee> bknudson, uh, because pecan sounds sexy?
18:50:17 <henrynash> morganfainberg: I added one otehr minor one taht was approved for Kilo (supression of “extra” attr in SQL DB entities)
18:50:23 <dolphm> gyee: i don't know what you're talking about, we're building a pastebin-backed distributed fernet key share
18:50:25 <morganfainberg> ayoung: we have an open API impact, and we can always change prio/drop them as needed at the summit
18:50:28 <morganfainberg> ayoung: this is not "in stone"
18:50:30 <bknudson> gyee: I've been using pecans all wrong then.
18:50:33 <amakarov> henrynash, ++
18:50:34 <ayoung> then I'm good
18:50:45 <gyee> dolphm, I mean sharing key among independent clouds
18:50:51 <jamielennox> bknudson: i'd like it for a couple of reasons, to get rid of our home grown wsgi that makes a mess, to get some structure to our models so i can find routes by api, not by component
18:50:56 <morganfainberg> bknudson: it would be a cleanup/tech-debt paydown on how we build the routing framework
18:50:59 <Rockyg> o/
18:51:00 <morganfainberg> and ^^ that
18:51:01 <gyee> dolphm, share among instances, absolutely
18:51:05 <stevemar> ayoung, ++
18:51:14 <marekd> ayoung: ++
18:51:16 <stevemar> ayoung, something will come down the pipeline for federation
18:51:24 <ayoung> I'd like to start policy now, if that is ok
18:51:29 <ayoung> 9 minutes
18:51:31 <jamielennox> bknudson: but i don't have any particular love for pecan, i just want to use some existing component
18:51:38 <geoffarnold> i'm focussed on reseller-style federation
18:51:41 <dolphm> gyee: and share with your end users. why make them auth with keystone when they can generate keys securely client-side?
18:51:44 <morganfainberg> ok sec and we will let rocky say 2 min thing then policy
18:51:46 <henrynash> morganfainberg: I’m not sure that it actually cahnges the API spec….so will move it to the other section
18:51:51 <Rockyg> sorry, missed most of the meeting, but I'd like to make sure tests that run on clouds in the wild, non-admin are part of the liberty cycle
18:52:28 <bknudson> isn't that a question for tempest?
18:52:30 <Rockyg> For trademark, but most importantly for interop between clouds and moving apps between clouds, we need to verify keystone key behaviors
18:52:43 <Rockyg> It is both tempest and defcore.
18:52:43 <morganfainberg> #info Non-API Impacting Priorities: 	stevedore for drivers(Approved, No-spec), Functional Testing (has spec, needs approval), Stable KSDI (has spec, against backlog), Fix Dependency Injection (has spec, needs approval), Pecan (needs spec), python3 (has spec, backlog), v3-only (no keystone spec needed), keystonemiddleware-uses-auth-plugins(code-ready, has spec, approved), Token Provider Cleanup
18:52:50 <gyee> dolphm, no, not sharing with end users, I mean sharing with neighbor clouds, I was responds to marekd's one token per cloud comment
18:52:56 <jamielennox> Rockyg: that's a good point - i don't know if we can do anything from keystone specifically - but maybe an inter-project thing at summit needs to be 'how to write admin-less policy files'
18:53:05 <dolphm> gyee: oh you're serious
18:53:06 <morganfainberg> #topic Testing admin-less
18:53:21 <Rockyg> The key is that there are certain assumptions tempest make that make testing outside of devstack hard
18:53:33 <bknudson> I assume there's already tempest tests for getting a token and using it.
18:53:42 <Rockyg> jamielennox: ++
18:53:46 <lbragstad> gyee: your key management story gets a little more complicated (not sure but I have a feeling security would be tough?)
18:54:06 <ayoung> gyee, I wrote that up years ago
18:54:06 <gyee> lbragstad, you did see the :) at the end of my first comment
18:54:09 <bknudson> I think getting a token and using it is the important part that needs to be standard
18:54:10 <ayoung> split on domain lines
18:54:15 <morganfainberg> lbragstad: gyee: please hold this convo until later
18:54:16 <Rockyg> also, basic tests that validate keystone enforces roles.  So negative tests that validate you get the right error message
18:54:25 <ayoung> "who can sign for what"
18:54:29 <morganfainberg> lbragstad: gyee: we have little time left
18:54:33 <ayoung> OK..policy
18:54:42 <morganfainberg> ayoung: sec. wait for Rockyg to finish
18:54:43 <Rockyg> Currently all of the tempest tests require admin privelege
18:54:59 <Rockyg> tenant admin is ok, but not cloud.
18:55:09 <ayoung> Rockyg, oof, yeah, that could be bad
18:55:11 <morganfainberg> Rockyg: and you want us to help with tests that would show API functionality w/o admin
18:55:12 <morganfainberg> ?
18:55:23 <Rockyg> Yes, please
18:55:28 <ayoung> Rockyg, you need the policy stuff I'm about to talk about
18:55:34 <geoffarnold> Not just w/o admin, but with domain-local admin
18:55:37 <Rockyg> cool.  OK.
18:55:40 <bknudson> keystone will need to have some users.
18:55:42 <morganfainberg> Ok, please think aobut that and we should help Rockyg out.
18:55:50 <morganfainberg> and this does play right into policy
18:55:51 <morganfainberg> so...
18:55:56 <morganfainberg> #topic Policy
18:55:59 <ayoung> OK...
18:56:01 <Rockyg> also, quickie, I think bknudson is the guy, but a liaison for log wg
18:56:01 <morganfainberg> ayoung: sorry about the limited time left
18:56:06 <jamielennox> Rockyg: so i made a start on that in tempest to assume a domain scoped token, but i think that'll mostly be a tempest issue
18:56:08 <ayoung> ioram, has a proof of concept of DB drive policy
18:56:16 <ayoung> they are using a library that is py3 only
18:56:32 <ayoung> ioram, want to expound?
18:56:34 <morganfainberg> ayoung: unfortunately we can't make things py3 only
18:56:39 <morganfainberg> (4min left)
18:56:47 <Rockyg> jamielennox: great.  Let's talk either elsewhere in IRC, or at the summit.
18:57:04 <ayoung> morganfainberg, but we can potentially make db-driven policy Py3 only.  It can be optional to start
18:57:05 <geoffarnold> Is there a wiki page on the policy ideas?
18:57:17 <ayoung> and, we can work towards splitting policy off of the rest of the Keystone server
18:57:24 <ioram> ok. hi guys. My PhD is on federated policy administration service for multi cloud environment.
18:57:33 <morganfainberg> ayoung: negative. i do not want py3 only code in the tree until we drop py27
18:57:35 <morganfainberg> sorry
18:57:46 <ioram> And I've been working on a database model to store Openstack policies.
18:57:56 <ayoung> morganfainberg, ok,  we'll have to work to backport the DNF code that they are using, or find an alternative
18:58:01 <morganfainberg> ayoung: yes.
18:58:10 <jamielennox> ayoung, morganfainberg: agree - but it's easier to support both py2/py3 if you start with py3
18:58:15 <ayoung> ioram, what is the library?
18:58:43 <morganfainberg> jamielennox: if the library is py3 only it's harder.
18:58:59 <ayoung> #link https://review.openstack.org/#/c/133814/
18:59:05 <ayoung> OK...since little time
18:59:16 <ayoung> henrynash, need you to stick around and discuss roles in #keystone
18:59:19 <jamielennox> morganfainberg: i mean surely they'll accept patches to support py2 as well
18:59:20 <ioram> The library is to transform any logical expression into DNF. The name is pyeda. https://pypi.python.org/pypi/pyeda
18:59:26 <morganfainberg> jamielennox: i hope
18:59:33 <david8hu> ioram, have you have a chance to review ayoung's https://review.openstack.org/#/c/133814/
18:59:43 <ayoung> david8hu, he
18:59:49 <ayoung> 's take n ownership of it
18:59:50 <morganfainberg> ioram: i'm not opposed to that, but we will need to make it either py2 compat as well *or* find an alternative
19:00:12 <ioram> The latest version don't support Py2.7, but I think there are some old ones that does. Maybe these old version also work for us.
19:00:12 <morganfainberg> ok we're out of time.
19:00:18 <ayoung> morganfainberg, I think that is fine.  Suspect Py27 would be easiest,
19:00:21 <morganfainberg> ioram: we will need to look into it
19:00:28 <samueldmq> ioram, I can also discuss with you some alternative post-meeting :)
19:00:30 <ayoung> everyone back to #openstack-keystone
19:00:31 <morganfainberg> so summit session planning in -keystone
19:00:39 <samueldmq> ioram, feel free to ping me to talk about it
19:00:43 <morganfainberg> lets let infra have their meeting slot
19:00:46 <morganfainberg> #endmeeting