18:03:07 <morganfainberg> #startmeeting Keystone
18:03:07 <openstack> Meeting started Tue Oct 28 18:03:07 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:10 <openstack> The meeting name has been set to 'keystone'
18:03:31 <morganfainberg> So we're headed to Paris!
18:03:32 <morganfainberg> woot
18:03:39 <dolphm> wait what
18:03:50 <marekd> ppl arriving Sat or Sun?
18:03:57 <lbragstad> I'll be there Saturday
18:03:58 <marekd> (some Monday i heard)
18:03:59 <bknudson> Sun
18:04:04 <morganfainberg> I'll be there on saturday morning
18:04:05 <dstanek> Sunday
18:04:07 <gyee> Sat morning
18:04:10 <ayoung> Sun early...overnight Saturday night
18:04:11 <dolphm> saturday morning
18:04:20 <raildo> Sunday
18:04:28 <bknudson> flying through MSP?
18:04:36 <lbragstad> I am!
18:04:36 * marekd Sunday
18:04:42 <lbragstad> bknudson: ^
18:04:42 <dstanek> i arrive at 7am give or take
18:04:55 <jamielennox> Sunday night
18:04:57 <bknudson> lbragstad: you'll be on the flight the day before.
18:05:15 <lbragstad> bknudson: yeah, friday night arriving Saturday morning
18:05:18 <topol> o/
18:05:19 <topol> Ill be there Sunday
18:05:26 <dstanek> for international fights is it better to carry-on or check baggage?
18:05:27 <bknudson> lbragstad: smart!
18:05:36 <topol> Sunday morning
18:05:39 <nonameentername> o/
18:05:41 <lbragstad> bknudson: we'll see
18:05:42 <morganfainberg> topol, nice - first round of cognac on you? :P
18:05:47 <topol> dstanek always best to carry on
18:05:48 <marekd> dstanek: both? :-)
18:05:54 <dolphm> dstanek: always carry on! but i'm doing both
18:05:54 <nonameentername> Saturday
18:06:01 <dolphm> critical stuff stays on my back :)
18:06:02 <morganfainberg> dstanek, depends on how long you'll be there
18:06:12 <morganfainberg> since i'm staying for an extra week i'll be checking clothing mostly.
18:06:14 <gyee> is there good place to get lub?
18:06:15 <dstanek> morganfainberg: only a week
18:06:33 <morganfainberg> for 1wk i'd do carry on unless you need lots of stuff
18:06:34 <dstanek> i almost always carry on, but i've never done international
18:06:39 <topol> I carried on even for 7 days to Hong Kong. I wont go back to checking bags
18:06:40 <bknudson> I'm also staying an extra week.
18:06:41 <topol> Had them get ripped to shreds in the past
18:06:55 <dolphm> topol: ++
18:07:01 <topol> dstanek if you can carry on definetly do that
18:07:05 <dolphm> i only brought my backpack to atl
18:07:18 <morganfainberg> topol, it's when you start hitting ~12-20 days it's hard to do as a single carryon internationally
18:07:25 <dolphm> morganfainberg: bring detergent
18:07:28 <dolphm> problem solved
18:07:33 <henrynash> morganfainberg: or hard to keep friends
18:07:43 <topol> morganfainberg if I leave for 12 days my wife will kill me. wont be a problem
18:07:48 <morganfainberg> dolphm, *or* abuse my friends in Lyon when i'm visiting for their washing mashine
18:07:53 <marekd> henrynash: unless they did the same.
18:07:54 <morganfainberg> ;)
18:08:06 <morganfainberg> henrynash, haha
18:08:16 <topol> dolphm, they sell it at the laundromats
18:08:24 <topol> we do that when we goto Italy
18:08:31 <ayoung> henrynash, you are sleeping at home each night, right?
18:08:37 <ayoung> just commuting via train?
18:08:44 <henrynash> ayoung: no..but nice idea!
18:08:51 <dolphm> travel size laundry soap http://www.amazon.com/dp/B001TUZS98/
18:09:01 <bknudson> I wouldn't want to spend my time in paris washing clothes.
18:09:01 <ayoung> Cuz crashing with you was my backup sleeping plan
18:09:13 <henrynash> ayoung: ah!
18:09:16 <bknudson> I can do that here.
18:09:18 <morganfainberg> bknudson, pay the hotel to do it for you. most will (even internationally)
18:09:40 <morganfainberg> ok so.
18:09:45 <morganfainberg> #topic Review of Keystone Blueprints for "Trivial" Status
18:09:51 <topol> ayoung how come you can never afford a room?
18:10:10 <jamielennox> ayoung: if you're looking at backup plans i'm well and truly screwed
18:10:11 <morganfainberg> We're going to try something new here. mostly this is just to cover the plan once we hit the swing of things.
18:10:16 <marekd> jamielennox: ?
18:10:28 <jamielennox> marekd: he organized my accom
18:10:28 <ayoung> topol,  "Backup"  meaning when jamielennox kicks me out.  once again he is subjected to sharing a room with me
18:10:35 <marekd> jamielennox: ayoung ?
18:10:58 <ayoung> marekd, same company, trying to keep down costs
18:11:18 <morganfainberg> #undo
18:11:19 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3577510>
18:11:20 <marekd> ayoung: i was a studnent not so long time ago - i know what you are talking.
18:11:58 <morganfainberg> ok we can discuss accomodations in -keystone
18:12:05 <morganfainberg> :)
18:12:09 <marekd> yes
18:12:09 <morganfainberg> #topic Review of Keystone Blueprints for "Trivial" Status
18:12:18 <bknudson> what are the blueprints to review?
18:12:48 <ayoung> Actually, morganfainberg you want to explain what is going on with backlog etc?
18:12:58 <morganfainberg> This is basically the way we're going to handle BPs that *dont* have a spec going forward, we will do a quick review each meeting and classify as "trivial" meaning no Spec needed
18:13:23 <topol> cool
18:13:26 <morganfainberg> if they are trivial they're approved and can be targeted for *this* milestone (or any)
18:13:31 <bknudson> maybe I'd get more reviews if I wrote up a bp.
18:13:32 <gyee> criteria for trivial status?
18:13:32 <morganfainberg> an example of trivial: Fix documents
18:13:35 <henrynash> morganfainberg: I have one: https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata
18:14:04 <morganfainberg> gyee,  i'm working on full details, but basically stuff that doesn't change the REST API, is something "we should just do"
18:14:07 <henrynash> morganfainberg: this might be a good test…it’s not as trivial as documentation
18:14:09 <bknudson> henrynash: doesn't affect the API?
18:14:12 <morganfainberg> and is self explanitory
18:14:17 <morganfainberg> e.g. CADF everywhere
18:14:32 <henrynash> bknduson: teh manager-driver api, yes, not the controller-manager api
18:14:48 <morganfainberg> yes we all agree we should make all notifications cadf, but do we need a big heavy formalized spec for it? probably not
18:14:54 <gyee> sounds reasonable
18:14:54 <henrynash> bknudson: which we may say, menas it’s not trivial?
18:15:06 <morganfainberg> so lets take a look at keystone-client ( henrynash we'll use yours in a sec )
18:15:09 <morganfainberg> #link https://blueprints.launchpad.net/python-keystoneclient
18:15:09 <bknudson> https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata seems basic enough to me.
18:15:18 <bknudson> I hate to call it trivial.
18:15:26 <henrynash> bknudson: :-)
18:15:44 <morganfainberg> if you look at the list ^ we're only interested in "undefined, new, and untargeted" BPs
18:15:57 <bknudson> keystoneclient bp isn't going to affect the rest api
18:16:01 <morganfainberg> for ksc there are 6.
18:16:18 <morganfainberg> bknudson, exactly and also because the list is short, i'm using it to explain things
18:16:19 <bknudson> I've got code for https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-i18n , just didn't know there was a bp.
18:16:22 <jamielennox> keystoneclient has always been a little weird about blueprints - i don't think it's just me
18:16:34 <morganfainberg> bknudson, that is also why reviewing these helps :)
18:16:49 <morganfainberg> jamielennox, yeah.
18:17:19 <dolphm> jamielennox: ++
18:17:32 <morganfainberg> so we're not oging to go through all of these this meeting. we'll pick just a couple ( like henry's ) and I'll finish cleaning everything up so the first meeting post summit we can start this process.
18:17:47 <dolphm> story board should unify the approach between clients & server
18:17:53 <morganfainberg> dolphm, ++
18:18:02 <dolphm> *excited*
18:18:03 <morganfainberg> and storyboard will help make this waaaaay better
18:18:22 <morganfainberg> ok so lets look at henry's bp now.
18:18:25 <morganfainberg> #link https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata
18:18:35 <jamielennox> not to derail again but do we expect storyboard soon?
18:18:42 <morganfainberg> jamielennox, not this cycle
18:18:49 <krotscheck> jamielennox: nope.
18:18:49 <morganfainberg> it's in beta for -infra to use
18:19:04 <morganfainberg> jamielennox, help krotscheck get storyboard in shape for everyone else :)
18:19:06 <krotscheck> jamielennox: Come to the lighting talk at the summit on monday to get an update.
18:19:10 <bknudson> we need a storyboard demo at the summit
18:19:19 <morganfainberg> ^^ lightning talk
18:19:32 <marekd> bknudson: what's a storyboard?
18:19:34 <krotscheck> The lightning talk is titled “Storyboard: Lightning Walkthrough"
18:19:36 <jamielennox> i'd be keen to see it, i saw some of the beta but didn't really look at all the features
18:19:45 <lbragstad> marekd: a new tracking tool to replace launchpad
18:19:55 <marekd> lbragstad: thanks.
18:19:56 <rodrigods> lbragstad, marekd, wow
18:20:32 <morganfainberg> ok
18:20:37 <morganfainberg> so Henry's BP
18:20:49 <morganfainberg> https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata
18:21:11 <henrynash> so this is non-trivial in that it isn’t, say, just documentation....
18:21:18 <morganfainberg> this looks like something that doesn't affect the API contract
18:21:40 <gyee> but involves migration
18:21:43 <gyee> data migration I mean
18:21:46 <henrynash> it does affect the manager->driver API….but not the controller->manaager API
18:21:52 <henrynash> gyee: no
18:22:14 <gyee> so the meta are leftovers?
18:22:28 <morganfainberg> henrynash, this might be a case because it affects more things that we want a spec, but i'm open for anything to be classified as "no spec needed" (as long as it doesn't change API contract)
18:22:30 <topol> henrynash you can just remove the role metadata and all is well?
18:22:41 <ayoung> Is there any demand to PKI signe CADF messages? Or sign at log rotation?
18:22:50 <ayoung> ah..sorry, I'm behind
18:22:51 <morganfainberg> ayoung, different topic
18:22:52 <henrynash> gyee: yes…a few old manager APIs use it…and the drivers “fake up” the metadata from the underlying data
18:23:20 <gyee> henrynash, k, I see
18:23:47 <dolphm> topol: it's about changing the "metadata" construction in the manager->driver API and replacing it with something more explicit
18:23:48 <morganfainberg> i could see this one go either way tbh.
18:23:54 <ayoung> then lets go spec
18:24:03 <ayoung> if there is a question...it probably means non-trivial
18:24:11 <henrynash> so I’m open to doing a spec if people think it needs it….I think this one is a good test of the border line
18:24:12 <ayoung> we can always downgrade if there isn't enough there
18:24:14 <topol> feels like it needs a spec
18:24:25 <henrynash> ok, done
18:24:25 <morganfainberg> i think this one would be better as a spec because there is a question of the more-explicit metadata -> other things
18:25:13 <topol> specs dont really help the dolphs and morgans of the world.  but as a member of the unwashed masses they really help me to understand keystone arch and direction
18:25:14 <henrynash> I think this one is probably the type that you people needs to see a spec before they could agree you didn;t need a spec :-)
18:25:25 <ayoung> Let me make this explicit:  if you are reviewing one of my specs, and you want to rewrite a section of it, please do so, and add yourself as a contributor/author
18:25:50 <morganfainberg> ayoung, i'll circle back on the backlog thing
18:26:01 <ayoung> until a spec is approved, lets treat them as collaborative documents
18:26:17 <henrynash> morganfainberg: let’s try and find one that we can agree that’s trivial so we can hone in where the boundry is
18:26:32 <morganfainberg> henrynash, looking for one now
18:26:33 <morganfainberg> actually
18:26:43 <ayoung> If it is a one line change already written
18:27:02 <henrynash> topol: unwashed?  is that a continuation of the “do i packa carry on or not for paris"?
18:27:10 <morganfainberg> henrynash, https://blueprints.launchpad.net/keystone/+spec/deprecate-ssl-functions
18:27:24 <ayoung> None of mine are Trivial
18:27:47 <topol> henrynash I refused to answer on the basis that I may incriminate myself
18:27:52 <morganfainberg> this one is likely something that we "don't" care about a spec for.
18:27:54 <morganfainberg> #link https://blueprints.launchpad.net/keystone/+spec/deprecate-ssl-functions
18:28:00 <morganfainberg> it's mostly affecting testing
18:28:25 <morganfainberg> if we make the mechanism for handling the "self signed CA" better, everyone wins
18:28:43 <ayoung> morganfainberg, I have a solution to that!
18:28:48 <morganfainberg> but it wont have massive impact on too many things outside of devstack
18:28:54 <gyee> dogtag? :)
18:28:58 <morganfainberg> and/or toy setups.
18:28:59 <morganfainberg> so.
18:29:07 <morganfainberg> thoughts on https://blueprints.launchpad.net/keystone/+spec/deprecate-ssl-functions ?
18:29:10 <dolphm> any blueprint that only affects keystone developers should be second guessed for necessity
18:29:13 <bknudson> not sure what the point is of making self signed CA more complicated.
18:29:17 <ayoung> Use Certmonger
18:29:19 <henrynash> ayoung: so on this one, we would explain how to set up certmonger (in the place of wherever we explain pki_setup)?
18:29:28 <ayoung> yep
18:29:33 <morganfainberg> basically.
18:29:35 <henrynash> ayoung: ok
18:29:43 <jamielennox> morganfainberg: so as much as i think yes trivial the advantage of a spec there is that later we can point someone to it and say why we did it
18:29:43 <ayoung> and...for the selfsign, we would use certmaster.
18:29:49 <ayoung> its a trivial CA
18:29:59 <bknudson> openssl is a trivial ca
18:30:01 <dolphm> or just get certs from anywhere not keystone
18:30:05 <jamielennox> morganfainberg: because as much as i consider that obvious it's used by enough deployments that someone will notice it missing
18:30:07 <morganfainberg> dolphm, exactly
18:30:17 <morganfainberg> jamielennox,  i'm not saying we want this bp
18:30:19 <dolphm> i don't see any reason at all why keystone should be advocating for certmonger
18:30:23 <morganfainberg> in fact i think it's not worth the effort
18:30:25 <topol> so here is a question. what I liked about the specs is I can always go and do a review and see what needed to be reviewed.  With trivial BPs now I have to look another place as well and do a merge/diff
18:30:29 <dolphm> there's an argument to make for devstack, i suppose
18:30:34 <morganfainberg> but, this is a case where the BP if we wanted it doesn't need a spec
18:30:42 <jamielennox> dolphm: ++ keystone doesn't care, just configure it with certs
18:30:46 <bknudson> it would be interesting to see it in devstack
18:30:49 <ayoung> https://fedorahosted.org/certmaster/
18:31:01 <morganfainberg> so in short, i'd say ditch this BP for keystone.
18:31:14 <morganfainberg> but it's not worthy of a spec even if we wanted it.
18:31:17 <ayoung> is XML RPC, in a stand alone server
18:31:20 <dolphm> jamielennox: and actually half of keystone's ssl / pki config options are so that it can generate it's own certs... so all those can go away
18:31:49 <morganfainberg> i'm actually a fan of repurposing this spec to "remove self-signed SSL options from keystone"
18:31:55 <jamielennox> dolphm: yep, cause they are really confusing options when you come to it with a cert already
18:31:58 <morganfainberg> and not care *how* we get there.
18:32:09 <bknudson> they can be changed to cli options on keystone-manage
18:32:25 <morganfainberg> e.g. "here is where you stick your certs"- how devstack works is not really keystone's scope.
18:32:26 <jamielennox> bknudson: remove the whole command from -manage
18:32:29 <topol> morganfainberg, because in real deployments the self-signed is never used correct?
18:32:29 <bknudson> if we still want to make it somewhat easy
18:32:32 <jamielennox> morganfainberg: ++
18:32:36 <morganfainberg> topol, , exactly
18:32:40 <bknudson> I'm also fine with removing the function
18:32:43 <jamielennox> morganfainberg: devstack already has a CA and cert generating component
18:32:46 <ayoung> I'd leave the command in manage and make it call certmonger functions instead
18:32:55 <ayoung> but this discussion ios beyond the scope of this meeting
18:32:55 <jamielennox> ayoung: nope - kill it
18:33:00 <morganfainberg> ok, so proposal: make this BP "remove self-signed cert generation options"
18:33:07 <morganfainberg> and call it a "no-spec needed" BP
18:33:13 <topol> jamielnnox ++ less code to learn/maintain :-)
18:33:48 <bknudson> I don't know if we need to deprecate the function
18:33:57 <bknudson> or if we can just remove it
18:34:01 <jamielennox> morganfainberg: +1 to change purpose, -1 to no spec - it doesn't need to be long but i think it's more about documenting why we removed it
18:34:03 <dolphm> this could just be merged into the deprecated-for-kilo bp wherever that is
18:34:19 <topol> bknudson may be right. how do we know some one didnt find a crazy use for it?
18:34:20 <morganfainberg> dolphm, i like that
18:34:21 <jamielennox> or merged into deprecated would be fine
18:34:32 <bknudson> our products use it.
18:34:46 <bknudson> but we can adapt to this one pretty easily
18:35:21 <morganfainberg> ok will kill this BP, with the comment that we should merge this topic into "removed-in-kilo"
18:35:26 <henrynash> so I agree this doesn’t need a spec, but just becasue it is a no-spec BP,  shoudl not mean it is any more likely to achieve agreement….we need to allow people to object just as a full spec BP
18:35:48 <morganfainberg> henrynash, we can discuss in code review and on the BP.
18:35:49 <jamielennox> i think pki_setup was my first keystone contribution - it seemed like a good idea at the time
18:36:12 <morganfainberg> henrynash, largely if there is a question it wont be "approved"
18:36:26 <morganfainberg> henrynash, and we can say "no agreement that this is trivial"
18:36:42 <henrynash> morganfainberg: yep
18:37:27 <morganfainberg> ah here is one
18:37:31 <morganfainberg> #link https://blueprints.launchpad.net/keystone/+spec/alembic
18:37:42 <morganfainberg> honestly, probably doesn't need a spec.
18:37:58 <bknudson> there are lots of questions around the conversion to alembic
18:37:58 <morganfainberg> it could help to have one but i think the spec will be "migrate data to alembic"
18:38:09 <morganfainberg> but i don't think a spec will answer them
18:38:15 <morganfainberg> in any meaningful way
18:38:21 <ayoung> I think there are a lot of devils hiding in the weeds with the migrations
18:38:22 <bknudson> is it only for new migrations,or is it existing ones, too?
18:38:42 <morganfainberg> this isn't a trivial bp, it is a "there isn't a lot of ways to do this, but lots of things to change?
18:38:43 <morganfainberg> "
18:38:46 <ayoung> what if we accect a hybrid
18:38:49 <dolphm> bknudson: i think ceilometer (?) did the transition successfully mid cycle using only new migrations
18:39:00 <ayoung> sql-a up to now, alembic assumes that SQL has been run first
18:39:03 <bknudson> seems like we do have to move away from sqlalchemy-migrate at some point since I think it's abandoned.
18:39:04 <jamielennox> morganfainberg: agreed, i don't think the spec will tell anything about the code direction - so BP is good for tying it together but i'm ok with a BP only
18:39:06 <morganfainberg> dolphm, that is the general direction we would like to go is possible
18:39:26 <ayoung> when we get to the point that we can collapse the migrations, and drop all of the sql-a ones, we drop sql-a
18:39:44 <bknudson> ayoung: I like that plan.
18:39:45 <dolphm> ayoung: ++
18:40:17 <morganfainberg> i'll change the topic in the meeting from "Trivial" to "No-Spec-Required"
18:40:17 <ayoung> should i #action that?
18:40:25 <morganfainberg> ayoung, sure!
18:41:06 <bknudson> we should make the decision that kilo is alembic or not before we get a migration
18:41:20 <ayoung> #action  Current SQl migrations will stay in SQL Alchemy.  New migrations will be done in Alembic.  We will have a Hybrid solution for a couple of releases until we can collapse all of the SQL-Alchemy ones into Alembic.
18:41:24 <dolphm> bknudson: well we need the support in db_sync to run both
18:41:30 <dolphm> bknudson: (first)
18:41:44 <dolphm> bknudson: when we accept that, the rest of kilo becomes alembic
18:41:54 <ayoung> ++
18:42:40 <dstanek> all these great details should get pushed into the blueprint or spec
18:42:48 <ayoung> dstanek, Agreed
18:42:51 <lbragstad> ++
18:43:02 <morganfainberg> ok
18:43:09 <morganfainberg> so lets move on. we have other topics to cover
18:43:18 <morganfainberg> ayoung, mind updating the spec?
18:43:20 <morganfainberg> erm bp
18:43:22 <ayoung> "When in doubt, spec it out."
18:43:22 <henrynash> maybe the spec-less BP is an urban myth?
18:43:25 <ayoung> Will do
18:43:31 <topol> ayoung +++
18:43:55 <morganfainberg> #topic QA Liason
18:43:57 <gyee> henrynash, nice!
18:43:58 <henrynash> (or maybe just a lot rarer than we thought)
18:43:59 <morganfainberg> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#QA
18:44:08 <morganfainberg> we need someone to take the role on.
18:44:12 <morganfainberg> (please)
18:44:24 <morganfainberg> this is the same as oslo and VMT liasons
18:44:25 <dstanek> henrynash: there is always something to argue about
18:44:28 <morganfainberg> just for QA
18:44:42 <dstanek> morganfainberg: as in tempest like stuff?
18:44:48 <morganfainberg> dstanek, yep
18:44:51 <lbragstad> so, same things as oslo liason?
18:44:53 <morganfainberg> dstanek, and the gate etc.
18:44:59 <dstanek> morganfainberg: i'll do that
18:45:03 <bknudson> everyt time the gate breaks you know they're going to blame keystone!
18:45:04 <lbragstad> I'll be backup
18:45:04 <dstanek> unless someone else wants to
18:45:13 <morganfainberg> dstanek,awesome please add yourself tot he wiki
18:45:37 <morganfainberg> #action dstanek QA Liason, lbragstad backup
18:45:41 <morganfainberg> #topic Keystone IRC Meeting Cancelled November 3rd and November 10th
18:45:54 <morganfainberg> we'll be at the summit and the post-summit one we likely don't have a lot to talk about
18:46:24 <morganfainberg> so next keystone meeting will be the 17th
18:46:49 <gyee> before thanksgiving
18:46:52 <marekd> Nov 10th is a monday ?
18:46:53 <morganfainberg> plus lots of people will either still be in France or jet lagged
18:47:02 <morganfainberg> sorry 11th
18:47:06 <morganfainberg> marekd, , good catch
18:47:22 <morganfainberg> #topic Keystone IRC Meeting Cancelled November 3rd and November 11th
18:47:28 <morganfainberg> and the next meeting is actually tyhe 18th
18:47:29 <bknudson> works for me.
18:47:42 <henrynash> err…can’t be the 3rd then either
18:47:59 <morganfainberg> #undo
18:48:00 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x366ff10>
18:48:05 <henrynash> 4th & 11th cancelled
18:48:18 <morganfainberg> #topic next keystone meeting is 18th. (yes i can't do date math--morganfainberg)
18:48:27 <morganfainberg> ok
18:48:33 <morganfainberg> #topic Scoping federated tokens with 'token' identity method
18:48:37 <morganfainberg> marekd, o/
18:48:40 <marekd> o/
18:48:48 <marekd> so that should be quick
18:49:21 <bknudson> doesn't it work now?
18:49:43 <marekd> we spoke with jamielennox last week about it, and it turns out that there is a relatively simple way to unify scoping federated classic tokens. No need to add extra method name 'saml2' or 'mapped'.
18:49:49 <marekd> just wanted to hear your opinions
18:49:55 <marekd> it's is now: https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-federation-ext.md#request-a-scoped-os-federation-token-post-authtokens
18:50:21 <marekd> and looks like we could use 'token' which would simplyfy few things, let us remove some code from keystoneclient
18:50:41 <bknudson> y, it's the same as getting a token from a token
18:50:52 <bknudson> what has to change, though?
18:51:02 <morganfainberg> bknudson, keystoneclient code/
18:51:03 <morganfainberg> ?
18:51:10 <marekd> no, keystonecode
18:51:12 <gyee> if the payloads are the same, then yes
18:51:13 <marekd> keystone code
18:51:18 <gyee> auth payloads I mean
18:51:19 <topol> do you change the info sent in on the restful APIs?
18:51:19 <marekd> gyee: payload are not the same
18:51:21 <ayoung> Um...that is not why we were doing that in the past
18:51:22 <jamielennox> bknudson: ++ that's kind of the point, i don't know why it was ever a different auth method anyway, it should have always just been token
18:51:31 <marekd> we need to differencitate if that a federated or 'classic' token
18:51:32 <ayoung> the "method" is what the client sets...like "kerberos"
18:51:39 <ayoung> as you recall, I didn't even want that...
18:51:41 <gyee> if the auth  payloads are not the same, then we need different identifications
18:51:49 <ayoung> can we just drop the methods all together?
18:51:58 <dolphm> ayoung: not really
18:52:02 <marekd> https://review.openstack.org/#/c/130593/1/keystone/auth/plugins/token.py
18:52:07 <ayoung> didn't think so, but worth asking
18:52:07 <marekd> i made a super quick fix
18:52:34 <morganfainberg> oh that is kindof slick marekd
18:52:58 <morganfainberg> meta programing without metaprogramming.
18:53:13 <marekd> morganfainberg: i don't say it's the best way - we could do some upper object TokenBase that would call either Mapped or Token classes
18:53:18 * morganfainberg wonders how that can break things
18:53:26 <gyee> that's kindda chaotic though, have to parse the payload in order to figure what it is
18:53:28 <morganfainberg> probably should do that.
18:53:35 <morganfainberg> if we're parsing payload
18:53:44 <marekd> but this is somewhere where this 'switch' needs to be done, as we must enter Token.authenticate() method
18:53:52 <morganfainberg> we're actually doubling the validate in this case
18:54:03 <gyee> we need something unambiguous
18:54:03 <ayoung> so method name should indicate what was used to request the token
18:54:20 <jamielennox> it would make the client side a whole lot easier - there is no reason that an unscoped federation token should be any different from a regular unscoped token
18:54:26 <ayoung> but, I'd be ok with the method being added to the token after the fact, and not be part of the token request
18:54:33 <ayoung> IN fact, I'd prefer iot
18:54:36 <ayoung> it
18:54:37 <dolphm> jamielennox: ++
18:54:37 <morganfainberg> my only concern here is we're doubling the validate call (very expensive)
18:54:49 <morganfainberg> (6 mins)
18:55:22 <morganfainberg> we can talk about this a little further in -keystone, but i think tokens should be tokens
18:55:30 <morganfainberg> not "federated tokens are special"
18:55:30 <gyee> unscoped token is unscoped token, there shouldn't be any differece
18:55:36 <ayoung> The issue I have is that I need different AUTH_URLS for Kerberos etc
18:55:39 <marekd> morganfainberg: it's a pure wip as i didn't know if its worth working on that
18:55:48 <marekd> morganfainberg: but looks like validation doesn't need to be done twice.
18:55:57 <morganfainberg> ok
18:56:00 <morganfainberg> need to move on
18:56:01 <marekd> anyway, is it worth working on that? no -2 objections?
18:56:09 <gyee> method and scope are two different thing
18:56:10 <morganfainberg> no objections from me :)
18:56:12 <ayoung> marekd, lets talk next week
18:56:17 <morganfainberg> #topic Hierarchical Multitenancy API spec
18:56:17 <marekd> ayoung: sure
18:56:20 <morganfainberg> rodrigods, o/
18:56:23 <ayoung> we might be able to go even further
18:56:23 <rodrigods> o/
18:56:26 <topol> does it break anything if someone was already using this?
18:56:27 <morganfainberg> (sorry you only have a couple mins)
18:56:28 <raildo> o/
18:56:30 <marekd> ayoung: yes yesyes!
18:56:32 <rodrigods> ok
18:56:35 <rodrigods> quick one: please please review  https://review.openstack.org/#/c/130103/ , it's a dependency from https://review.openstack.org/#/c/117786/ (once we had a plan that everything would be merged by the summit or just after it)
18:56:41 <rodrigods> that's it =)
18:56:49 <raildo> ++
18:57:12 <morganfainberg> please aim to get them reviewed merged as close to summit/post summit as possible
18:57:25 <bknudson> seems strange that an extension is modifying the core API
18:57:29 <gyee> k
18:57:30 <rodrigods> will be here to do fix as soon we have -1s
18:57:44 <morganfainberg> bknudson, i want to talk about extensions at the summit
18:57:49 <morganfainberg> hallwaytrack/pod
18:57:54 <morganfainberg> #topic Splitting up Assignments
18:57:56 <morganfainberg> henrynash, o/
18:57:59 <morganfainberg> real quick!
18:58:00 <bknudson> y, another way to put it is why is HMT an extension
18:58:13 <henrynash> ok , wanted to get a quick read on if people are gnerally supprotinve of this
18:58:24 <rodrigods> bknudson, it isn't, just the inherited roles part is
18:58:28 <dolphm> (2 min)
18:58:35 <gyee> henrynash, yes
18:58:37 <morganfainberg> henrynash, it makes logical sense to me.
18:58:57 <henrynash> any violent objections?
18:59:00 <ayoung> Lets make Domains into projects and nest projects and call them tenants
18:59:14 <ayoung> damn...too slow again
18:59:21 <henrynash> ayoung: we can do that nicely once we have split this up!
18:59:31 <ayoung> henrynash, do roles stay with domains?
18:59:51 <henrynash> yes….domains, project and roles are the “base entities”
18:59:55 <dstanek> Trivial question that came up in a review. LOG.warn vs LOG.warning? Should we standardize?
19:00:01 <morganfainberg> and thats time., take it to -keystone please
19:00:04 <morganfainberg> #endmeeting