17:00:41 <geoffarn_> #startmeeting mercadorproject
17:00:42 <openstack> Meeting started Fri Jul 24 17:00:41 2015 UTC and is due to finish in 60 minutes.  The chair is geoffarn_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:45 <openstack> The meeting name has been set to 'mercadorproject'
17:01:33 <geoffarn_> Anyone here? If not, we can keep it short.
17:01:40 * shaleh raises hand
17:02:06 <raildo> \o
17:02:07 <okrieg> here
17:02:12 * geoffarn_ wonders why my IRC client has switched IDs
17:03:17 <geoffarn_> So gyee and I met yesterday at HP (with others),
17:03:32 <geoffarn_> and we're pulling together design docs
17:03:54 <geoffarn_> Hope to get them up today or tomorrow
17:03:59 <raildo> great
17:04:58 <geoffarn_> The basic question has been, if we build the publisher and subscriber to configure the two Keystones, will everything just work the way it's supposed to?
17:05:13 <geoffarn_> I.e. do we need to tweak Keystone?
17:05:46 <geoffarn_> For the first POC, the answer seems to be that it'll work OK
17:06:18 <okrieg> I thought that something was going to be needed to handle remote tokens?
17:06:50 <okrieg> based on chat we had the other day, i.e., subscriber getting token from publisher...
17:06:52 <shaleh> okrieg: for the user to auth and work yes, for pub/sub likely not
17:06:55 <geoffarn_> Not a problem, as it turns out
17:07:26 <okrieg> shaleh: that seems pretty fundamental
17:07:46 <okrieg> what good is pub/sub if we can't use it :-)
17:08:01 <geoffarn_> In the long term, we'd like to move a lot of the stuff into Keystone
17:08:31 <geoffarn_> The pub/sub handle the business logic and policy
17:08:45 <shaleh> okrieg: agreed and it will be done for the POC
17:09:01 <shaleh> okrieg: geoffarn_  said no tweaking needed for pub/sub
17:09:37 <shaleh> we are going to try making a custom token provider and see how far that gets us
17:09:39 <geoffarn_> However right now we can use pub/sub to relay the tokens from pub to sub, so that the user on the sub side only sees valid tokens with endpoints in the pub cloud
17:10:18 <okrieg> think I need a picture
17:10:29 <shaleh> okrieg: :-) on their way
17:10:58 <geoffarn_> okrieg we don't need to tweak Keystone. The pub and sub services can configure both keystones
17:11:07 <shaleh> gyee has some slides made, he is about to go on a holiday. When he gets back the wiki will be updates
17:11:47 <geoffarn_> Right - and I'm updating the sequence diagrams and API to match gyee's slides
17:12:05 <davidjc> we can temporarily move some keystone complexity into an agent, and then merge capability
17:12:25 <geoffarn_> THe fundamental thing is that no Keystone every has to validate a token that it hasn't generated
17:12:35 <geoffarn_> every -> ever
17:12:46 <shaleh> geoffarn_: ++
17:12:48 <okrieg> hmmm, so user talkes to native keystone in each region, pub/sub configures the keystone on each side to get identity from sub, okay, I guess I grock it.  Is that correct, the client always goes to the native keystone for pub region?
17:13:11 <geoffarn_> "generated" isn't the same as "provided"
17:13:12 <okrieg> geoffarn_: makes sense
17:14:03 <shaleh> okrieg: yes. Just like in k2k federation today
17:14:20 <shaleh> okrieg: the plan is to remove the onerous numerous intermediary tokens
17:15:53 <okrieg> not sure I understand where the intermediary tokens come from.
17:15:58 <geoffarn_> We're meeting f2f again Tuesday to review/plan the POC implementation approach. Key requirement is to be demo-ready by mid-September
17:16:47 <shaleh> okrieg: have you used a k2k federation as the user of a service?
17:18:04 <okrieg> shaleh: we are playing with k2k in the lab, for the mix and match federation work, should probably get deeper on it.
17:20:27 <geoffarnold> I'm back - my corp VPN just crashed
17:20:37 <shaleh> okrieg: basically you ask "home" keystone for a token, then you need to convert it to a SAML2 request, then you get an unscoped token from "foreign" keystone, then you finally ask for a scoped taken from foreign
17:20:59 <shaleh> okrieg: this is all down by the consumer of the service, in code or commands
17:21:04 <shaleh> s/down/done/
17:21:47 <geoffarnold> Obviously this provides a lousy (non-transparent) UX, which is one thing we're trying to fix
17:22:18 <raildo> ++
17:23:03 <okrieg> yes, that's exactly what we are doing right now with the mix/match federation
17:23:17 <okrieg> woudl be super awsome if we could use the pub/sub infrastructure to get rid of that
17:23:51 <shaleh> okrieg: we are thinking a customer token provider with a mapping could allow the request to be done server side
17:23:51 <geoffarnold> The intent is that pub/sub sets things up for you
17:23:59 <shaleh> s/customer/custom/
17:24:29 <okrieg> awesome!
17:24:49 <shaleh> okrieg: plans and reality though, we shall see
17:25:37 <geoffarnold> The mercador use case is fairly straightforward, because we don't require or expect mixing and matching
17:25:49 <okrieg> we can design so we can shim in
17:25:59 <geoffarnold> endpoint groups are homogeneous with respect to auth
17:26:11 <geoffarnold> not true for Mix & Match
17:26:54 <shaleh> geoffarnold: once we can show it working they may be able to dupe and transform for their needs
17:27:05 <geoffarnold> agreed
17:27:20 <geoffarnold> may be use, maybe extend
17:27:42 <geoffarnold> raildo, what's next for reseller?
17:28:33 <raildo> geoffarnold: we finish the implementation to use is_domain in the token response... so right now we can put is_domain in the policy.json
17:28:51 <raildo> fow now, we are just fixing some code reviews in the patches
17:29:04 <geoffarnold> ok
17:29:37 <geoffarnold> At some point (prob at the same time as APIv4) we need to fix domain namespace
17:29:41 <raildo> please review :)  #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/reseller,n,z
17:30:30 <geoffarnold> Are you assuming that reseller will handle domain naming for its customers?
17:31:09 <raildo> hum.. I think so
17:31:41 <geoffarnold> Same as Mercador. We should align user stories
17:32:00 <raildo> ok
17:32:38 <raildo> geoffarnold: I think that we need to think more about the next steps for reseller in M release
17:32:50 <raildo> and how to improve it to Mercador
17:32:59 <geoffarnold> I really want to understand how we can create a real "virtual region", like a "virtual machine" - potentially nested arbitrarily deep
17:33:21 <geoffarnold> raildo +1
17:35:48 <geoffarnold> I've got a building maintenance guy at the door who wants to turn off my electricity for 15 minutes. I think we'll wrap this up here.
17:36:16 <geoffarnold> Bye...
17:36:30 <geoffarnold> #endmeeting
17:36:40 <raildo> have a good weekend
17:37:20 <geoffarnold> Ah, I'm now "geoffarnold" rather than "geoffarn_"
17:39:54 <geoffarn_> #endmeeting