18:02:42 <stevemar> #startmeeting keystone
18:02:43 <openstack> Meeting started Tue Oct 22 18:02:42 2013 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:44 <dolphm_> lol honorable attempt
18:02:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:47 <openstack> The meeting name has been set to 'keystone'
18:02:49 <gyee> we usually turn the meeting into a beer bash if the chair is not around
18:02:52 <morganfainberg> stevemar, haha i was typing that as you did it.
18:03:02 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:03:04 <dolphm_> success
18:03:16 <stevemar> #topic Reserved migration numbers for havana
18:03:32 <stevemar> looks like it's continuing from last week
18:03:49 <ayoung> KEYSTONE!
18:03:52 <dolphm_> p.s. everyone's homework was to read up on reserved migrations
18:04:16 <joesavak> whoops.
18:04:22 <dolphm_> have we had any migrations merge since last week?
18:04:28 <morganfainberg> dolphm_, don't think so
18:04:32 <stevemar> dont think so
18:04:35 <bknudson> what would require a migration?
18:04:36 <dolphm_> slash, since rc1
18:04:50 <ayoung> looking
18:05:10 <bknudson> I thought morganfainberg had some late fixes to migrations...
18:05:11 <dolphm_> if we've had anything merge, this this topi is moot
18:05:16 <dolphm_> topic*
18:05:28 <gyee> since most new features start out as extensions, there should be very little migration if any
18:05:28 <morganfainberg> bknudson, that was logic to a migration that was already there
18:05:33 <morganfainberg> bknudson, for sqlite
18:05:44 <morganfainberg> no new migration(s)
18:06:01 <dolphm_> gyee: interesting point- we'd need reserved migrations for extensions as well
18:06:16 <gyee> dolphm_, wait, I thought extensions are different
18:06:32 <morganfainberg> gyee, if we're putting in reserves for one, we should for the other.
18:06:39 <stevemar> agreed
18:06:40 <ayoung> dolphm_, we could do them like BASIC programs, and number them 5, 10, 15...
18:06:58 <morganfainberg> ayoung, i.. i.. i have no words
18:07:00 <gyee> k, I am fine with reservation
18:07:00 <ayoung> then if we need to instert a migration between 10 and 15 make it 12
18:07:00 <dolphm_> ayoung: they need to be sequential
18:07:01 <morganfainberg> ayoung, brilliant!
18:07:13 <ayoung> poke 53280,1
18:07:14 <morganfainberg> unfortunately, what dolphm_ said
18:07:31 <gyee> low hanging fruit
18:07:32 <joesavak> 1, 2, 3 - then if we need to insert one; 1.1?
18:07:33 <morganfainberg> dolphm_, how many reserved numbers do you think we need?
18:07:34 <joesavak> ;)
18:07:44 <stevemar> joesavak, if only
18:07:49 <bknudson> looks like Nova had placeholders in grizzly and never wound up using them.
18:07:53 <dolphm_> 3 in extension repos, 5-10 in core?
18:07:57 <ayoung> dolphm_, what if we have a separate repo for back fixes?
18:08:08 <morganfainberg> ayoung, how would that work?
18:08:27 <dolphm_> ayoung: that wouldn't be tranparent
18:08:52 <bknudson> I don't think it'll hurt anything to add the placeholders, and could potentially come in handy, so why not?
18:08:58 <dolphm_> is anyone strongly opposed to reserved migrations?
18:09:04 <morganfainberg> dolphm_, not opposed.
18:09:07 <stevemar> not i
18:09:15 <dolphm_> bkhudson: agree
18:09:19 <morganfainberg> i'd say 3 in extensions, 5 in main max though
18:09:19 <stevemar> sounds like they'll be handy
18:09:21 <topol> sounds good
18:09:23 <ayoung> or...beter yet, a separate repo for Icehouse fixes
18:09:57 <ayoung> so once we backport a fix to Havana, we adjust the fixes in the Icehouse repo to account for them....just a thought
18:09:58 <morganfainberg> nova _never_ used them.  i don't really think we're going to, but they are mostly harmless if they exist.
18:09:58 <gyee> I see *each* extension have their own migration_repo dir
18:10:07 <gyee> so we are saying, 3 reservations per repo?
18:10:16 <morganfainberg> gyee, i would say at most.
18:10:23 <morganfainberg> 3.
18:10:25 <gyee> k
18:10:47 <ayoung> I think reservations is the wrong approach.  I have a thought...let me collect it and write it up
18:10:48 <dolphm_> that works
18:10:53 <morganfainberg> ayoung, ok.
18:11:02 <stevemar> ayoung, sure send it to ML
18:11:13 <stevemar> so that gets chalked up as an action item?
18:11:24 <ayoung> yeah
18:11:29 <morganfainberg> dolphm_, slightly related, we doing a collapse of the migrations this time around? or?
18:11:29 <stevemar> any volunteers? :)
18:11:46 <ayoung> #action ayoung write up approach to backporting migrations using separate repo
18:11:51 <gyee> #action ayoung to turn on his light bulb on migration reservation?
18:11:52 <dolphm_> I'll do the reservations
18:12:04 <dolphm_> if someone wants to do the work of collapsing, go for it
18:12:06 <stevemar> #action dolphm to look at reservations
18:12:21 <stevemar> next topic, way more fun
18:12:23 <morganfainberg> dolphm_, i'll see if I can make that happen.
18:12:23 <dolphm_> stevemar: what's next?
18:12:25 <stevemar> #topic Reviewing design summit schedule
18:12:31 <stevemar> #link http://summit.openstack.org/
18:12:35 <stevemar> for my topic
18:12:41 <morganfainberg> #action morganfainberg look into collapsing migrations
18:12:41 <stevemar> err, sort*
18:12:47 <stevemar> sort by topic ... sigh
18:12:48 <dolphm_> I left comments on a bunch of sessions
18:12:52 <ayoung> dolphm_, reservations are not going to work.  When the repo says wee are at revsion X we need to know what that means....
18:12:54 <gyee> dolphm_, session on fixing service catalog?
18:13:07 <stevemar> dolphm_ how many session spots do we have?
18:13:21 <dolphm_> 9
18:13:34 <gyee> the remaining 20 will be conducted in a pub
18:13:35 <dolphm_> I'd like to split federation and the client session
18:13:45 <dolphm_> gyee: ++
18:13:58 <morganfainberg> gyee, ++++++++
18:14:09 <stevemar> currently there are 11 proposed sessions, so lets try to find some that can be consolidated
18:14:26 <ayoung> federation and client should be separate.  Very different topics
18:14:26 <gyee> stevemar, we can also try unconference
18:15:03 <stevemar> gyee: yup, but that gets busy too; and there might be some sessions that are closely related
18:15:22 <morganfainberg> if we can set a goal for the extensions one it can be merged with Internal API stabilization topic
18:15:28 <ayoung> HTML is refused...that gets us down to 10
18:15:34 <stevemar> dolphm, i see you refused 2 sessions already
18:15:34 <morganfainberg> they are both code management / approach
18:15:45 <ayoung> Extension mechanisms can hang on something else
18:15:53 <dolphm_> i think i refused domain scoped tokens
18:15:58 <stevemar> ayoung: yeah, V3 API Domain Scoped Tokens and HTML for Keystone have been refused
18:16:00 <dolphm_> if not, it can be
18:16:28 <ayoung> morganfainberg, that was my thought as well
18:16:32 <dolphm_> we've gotten bugs to simply doc that better
18:16:34 <morganfainberg> ayoung, 100% agree with it.
18:16:42 <ayoung> but lets leave it as is unless any more topics come in
18:16:49 <morganfainberg> right.
18:17:55 <stevemar> okay, if need be, we can merge those 2 sessions, Internal API Stabilization and Extension Mechanisms
18:18:05 <stevemar> only as a last resort :)
18:18:19 <gyee> there are other session which will have Keystone impacts, i.e. killing pagination
18:18:28 <topol> Did  	Auditing AuthN, AuthZ and Policy Decisions get accepted?
18:18:38 <stevemar> topol, not yet
18:18:40 <dolphm_> the client session description is way too big for a single session
18:19:23 <morganfainberg> dolphm_, perhaps we should expand the client one to 2 sessions and collapse the extensions and API stabilization ones to a single one?
18:19:29 <stevemar> dolphm_ suggest merging (internal API stabilitaion and extension) to get another client session?
18:19:35 <stevemar> morganfainberg +1
18:19:38 <morganfainberg> stevemar, ++
18:19:41 <gyee> dolphm_, that's because we have too many client issues to fix :)
18:19:44 <dolphm_> sounds good
18:19:49 <ayoung> works for me
18:20:02 <morganfainberg> i'll update mine and incorporate the extension stuff ayoung,
18:20:14 <dolphm_> the "ignoring the API, what should the client look like" is perfect for the summit
18:20:16 <stevemar> #action dolphm, refuse one of the sessions, update the comments and create a new session for client
18:20:20 <dolphm_> that should be its own session
18:20:33 <ayoung> Sounds good.  morganfainberg once you do, tag my session and I'll drop it
18:20:35 <bknudson> it should be async!
18:20:44 <morganfainberg> ayoung, will be done today.
18:20:49 <stevemar> awesome
18:21:00 <ayoung> bknudson, so keystone should respond to AMQP?
18:21:01 <stevemar> do we need 2 sessions for federation?
18:21:11 <ayoung> No, one session for federation
18:21:23 <ayoung> if it is going to take more than one, it is not going to be done in 2 either
18:21:29 <jamielennox> dolphm_: i'm not sure how much of that client stuff we'll need to cover but i don't mind a seconds session
18:21:29 <dolphm_> there's a LOT of material there
18:21:32 <morganfainberg> stevemar, i think one session should be enough.  we can unconference anything else that comes up
18:21:37 <stevemar> i think if we can schedule it at the end of the day, we can take up any arguments at a pub later :)
18:22:04 <gyee> yes sir
18:22:09 <jamielennox> discovery is happening already, everyone hates auth_token, APIClient and Versioning are my two main ones
18:22:20 <morganfainberg> dolphm_, i think it'll be more about chopping things and slating for J if we're _that_ full of federation stuff.
18:22:23 <dolphm> \o/ desk!
18:22:28 <morganfainberg> dolphm, yay!
18:22:29 <ayoung> We have an approach, and we are, I think tracking.  Federation session should be level setting so that we can continue any long term discussions after the conference.  But I thik we are finally positioned to implement Federation in the context of the other parts of Keystone, something that was not true until Havana
18:22:54 <joesavak> ayoung +1
18:23:12 <ayoung> What about globally unique IDs, though
18:23:23 <ayoung> that is not really Federartion, but came up in the context of LDAP
18:23:35 <ayoung> do we need an LDAP session?  Henrynash is not here, topol ?
18:23:42 <bknudson> sounds like federation.
18:23:49 <ayoung> bknudson, nope
18:24:11 <joesavak> federation handles it by user-passed-in-assertion@trusted-idp
18:24:14 <topol> LDAP seems pretty much under control now from my view
18:24:27 <ayoung> bknudson, similar, but this is for the case where we have a user store managed by Keysteon as well as a multiple LDAP stores.  It ties in with henrynash's assignmnet API talk, though
18:24:30 <morganfainberg> ayoung, i don't think we will ever have a lack of LDAP stuff to talk about, but not sure if we need a session.
18:24:45 <stevemar> morganfainberg ++
18:25:13 <bknudson> LDAP could be refactored into a read-only / read-write / ActiveDirectory implementations.
18:25:16 <stevemar> dolphm_ sorry, the people have spoke, 1 session for federation
18:25:25 <ayoung> dolphm, will get to talk about "The state of Keystone" as the PTL, and can level set on where LDAP is and is going to the community
18:25:30 <topol> multiple LDAP stores are really cool. but do we need enough steering ont hat to merit a session?
18:25:32 <bknudson> could also do connection pooling.
18:25:32 <gyee> agreed, I think we have enough on LDAP already, let the consults make money off integration :)
18:25:35 <morganfainberg> bknudson, that actually would be a good approach.
18:25:41 <gyee> consultants
18:25:47 <stevemar> #action everyone to read the sessions over and provide some comments :)
18:25:50 <morganfainberg> gyee, lol
18:25:53 <ayoung> topol, we need a way to figure out which backend to look at for a given user id
18:25:54 <dolphm> stevemar: i think 1 session is crazy for such a big topic
18:26:00 <topol> I would +1 gyee statement but then would need to go take a shower
18:26:03 <ayoung> its a generic problem, but driven home by LDAP
18:26:10 <ayoung> but Federation will have the same issue
18:26:14 <dolphm> it'll definitely be the single biggest change for icehouse
18:26:25 <joesavak> +1 topol's statement
18:26:26 <ayoung> We can try to cover it in Federation, but I'm afraid it would get lost
18:26:26 <joesavak> ;)
18:26:38 <gyee> ayoung, leave some money on the table for the consultants
18:26:41 <morganfainberg> dolphm, i am not opposed to 2 sessions, but i think we will mostly be level setting for J if we have more than 1
18:27:02 <morganfainberg> dolphm, just unlikely that we'll see all the change by I2.
18:27:28 <morganfainberg> dolphm, there is likely to be value in level setting the federation direction though
18:27:53 <dolphm> morganfainberg: i'm thinking with two sessions to help get everyone on the same page concerning the work that's been done and what we want to accomplish, we're more likely to see it done by i2
18:28:35 <morganfainberg> dolphm, fair enough, so 2 client, 2 federation, and collapse 2 of the other sessions?
18:29:00 <stevemar> then we need another volunteer to combine a session
18:29:14 <ayoung> Extensions goes into API stabilization
18:29:26 <stevemar> yup
18:29:36 <morganfainberg> ayoung, right, if we expand to a 2nd federation session, we need to collapse another set
18:29:53 <stevemar> was centralized quota storage already talked about last summit?
18:30:02 <ayoung> Do wereally need a Quota talk?  I thought that was a done deal?
18:30:09 <stevemar> ayoung, yap
18:30:16 <ayoung> We are doing quotas, it just is not done yet
18:30:32 <ayoung> design was signed off on,  just the develpoer got stuck in the review process
18:30:37 <morganfainberg> yeah that seems redundant to do that in two subsequent sessions
18:30:38 <dolphm> ayoung: agree
18:30:40 <morganfainberg> erm summits
18:30:44 <morganfainberg> so, we can drop that one.
18:30:56 <dolphm> ayoung: we weren't quick enough to respond to their patchsets either
18:31:14 <aguzikova_home> ayoung, we have https://review.openstack.org/#/c/37545/ also for quotas
18:31:28 <morganfainberg> ok so as long as we get quota stuff reviewed and accepted, we shouldn't need a session on it.
18:31:32 <gyee> dolphm, ayoung, I think there were some unfinished business with quota, the usage aggregation part
18:31:40 <aguzikova_home> not just domaint quota management
18:31:41 <stevemar> yeah, it seems generally accepted
18:31:44 <gyee> but I am not sure if it really belong to keystone anyway
18:31:53 <morganfainberg> aguzikova_home, ah.
18:32:01 <ayoung> gyee, but it would be really cool if Keystone tokens had the quotas signed in them.
18:32:03 <stevemar> sounds like the axe is falling on this session topic
18:32:15 <morganfainberg> stevemar, sounds like
18:32:39 <dolphm> i'm pushing sessions around now, btw
18:32:54 <bknudson> are the sessions all on one day?
18:32:56 <ayoung> yeah, tell them to have a quota unconference and work out the last remaining issues.
18:33:04 <bknudson> wasn't there a security track last time?
18:33:05 <morganfainberg> ayoung, ++
18:33:06 <gyee> ayoung, sounds good
18:33:10 <aguzikova_home> +1
18:33:20 <stevemar> #action dolphm to refuse quota session
18:33:22 <morganfainberg> bknudson, i think so… i don't remember
18:33:26 <dolphm> stevemar: done
18:33:42 <morganfainberg> sounds like we're doing 2 federation sessions then
18:33:57 <dolphm> is the Assignments session good as is?
18:34:12 <dolphm> there's three topics there -- i'm not sure the second one is worthy of summit time
18:34:23 <bknudson> is there any real argument about what needs to be done for assignments?
18:34:24 <dolphm> that's just a "yes, we need to clean up the sql impl"
18:34:34 <gyee> bknudson, lots
18:34:35 <ayoung> I'll do an unconference on the HTML thing.  I really just want a chance to demo it and don't currently have public hosting available.  Need to set up one of those Rackspace developer accounts.
18:34:37 <morganfainberg> pretty much we need to cleanup interfaces controllers, etc
18:34:40 <dolphm> bknudson: henrynash wants a whole new HTTP API for assignments
18:34:44 <gyee> like role-service
18:34:49 <dolphm> gyee: no
18:34:58 <morganfainberg> dolphm, wouldn't that be API version increment?
18:35:17 <morganfainberg> or is he saying as an extension?
18:35:25 <gyee> dolphm, we still have use cases with role assignment need to solve
18:35:25 <dolphm> morganfainberg: if you're dropping support for something, yes
18:35:36 <gyee> we also need to simplify assignment APIs
18:35:40 <dolphm> gyee: i'm more interested in the new use cases
18:35:45 <ayoung> assignments will have enough trickiness in it that it should have its own session, but maybe that can be combined with Federation.
18:35:51 <bknudson> we also need to simplify identity APIs
18:35:58 <morganfainberg> ayoung, nah.
18:35:59 <dolphm> if there's a use case for having metadata on an assignment, then a first class collection makes sense
18:36:02 <ayoung> It really is the ID/Assignment split that allows Federation to work
18:36:03 <morganfainberg> ayoung, don't combine it
18:36:12 <stevemar> i thought we're good, no need to continue trimming sessions
18:36:24 <dolphm> ayoung: -- for combining with federation
18:36:36 <stevemar> if we cut domain, then we have room for federation pt 2
18:36:37 <atiwari> Guys, I appreciate your focus on #link https://review.openstack.org/#/c/37141 again, as the solution proposed by ayoung is not addressing all use case.
18:36:40 <gyee> dolphm, ayoung, yes, assignment will be heavily impacts with federation as well
18:36:49 <gyee> especially on the mapping
18:36:50 <stevemar> ugh, i meant quota
18:37:23 <morganfainberg> gyee, dolphm, ayoung, the assignment one should just be scheduled around the federation ones… so we are in the same mindset if we can
18:37:40 <gyee> morganfainberg, sure
18:37:43 <ayoung> atiwari, we're discussing session for the summit...we'll address that in a few...
18:37:45 <dolphm> created a placeholder
18:37:46 <dolphm> http://summit.openstack.org/cfp/details/346
18:37:48 <topol> morganfainberg +1
18:38:25 <gyee> also, the auditing part will be very interesting, especially with mapping
18:38:40 <atiwari> ayoung, thanks
18:38:48 <morganfainberg> so back to the original question, dolphm, i think assignment one is good.
18:38:58 <ayoung> gyee, yeah, but auditing actually is tied with  policy , which is not even a Keystone project, and if it were, would be part of the client
18:39:32 <ayoung> for audit what tokens a user requested is not nearly so important as figuring out what they did with them
18:39:41 <gyee> ayoung, no, like given a user, tell me what he can do
18:39:54 <ayoung> morganfainberg, we can add atiwari '
18:39:57 <gyee> or given a resource, tell me who can do what to it
18:39:58 <morganfainberg> dolphm, ack, you pre-approved the API one, i can't edit it now
18:40:02 <ayoung> s concerns to the assignments session
18:40:18 <topol> ayoung, doesnt auditing need to be done on the server to make sure we catch everything?
18:40:21 <ayoung> atiwari, are you going to the summit
18:40:23 <dolphm> morganfainberg: crap
18:40:25 <atiwari> yes
18:40:29 <gyee> topol, percisely
18:40:35 <ayoung> topol, auditing needs to be done on each machine, not just Keystone
18:40:45 <morganfainberg> dolphm, lol can you set it back to unreviewed, i'll get the exention stuff added to it and ping you shortly?
18:40:45 <dolphm> morganfainberg: fixed
18:40:48 <morganfainberg> k
18:40:56 <topol> ayoung, both Im thinking
18:41:01 <dolphm> i'll stop pre-approving stuff lol
18:41:11 <stevemar> dolphm: that is probably a good thing :)
18:41:30 <stevemar> so, there sounds like there is interest in auditing
18:41:47 <jamielennox> dolphm: if you unset the client i'll remove some of those points - there's really just the two in there now i really want at summit the others can be later
18:41:57 <jamielennox> client summit session
18:42:01 <gyee> stevemar, the auditing aspect is generally missing :)
18:42:20 <ayoung> atiwari, we have a session for assignments   http://summit.openstack.org/cfp/details/131  please add your topic to that.  I think that it is the right place to discuss it
18:42:25 <stevemar> #link https://etherpad.openstack.org/p/keystone-sessions-icehouse something i quickly wrote up
18:42:44 <atiwari> ayoung, sure
18:43:01 <stevemar> we have 9 spots, and 9 currently proposed sessions... i think we're good assuming no one is against any session in particular
18:43:23 <dolphm> jamielennox: working on it
18:44:01 <ayoung> if anything else comes up, schedule unconference sessions for it.  Everyone should sign up for a twitter account, as that was really useful for tracking who was where at the summit, and posting unofficial announcements
18:44:08 <stevemar> ayoung +1
18:44:11 <dolphm> k, everything is unreviewed or refused
18:44:14 <ayoung> Og..and everyone make sure your shots are up to date
18:44:18 <topol> ayoung +1
18:44:18 <ayoung> Hep A and Typhoid
18:44:27 <morganfainberg> ayoung, yes
18:44:28 <atiwari> ayoung and dolphm, this may also be a good topic for session? #link https://blueprints.launchpad.net/keystone/+spec/attribute-access-privilege-based-on-role
18:44:29 <ayoung> and flu
18:44:30 <gyee> unreviewed for unconference
18:44:31 <jamielennox> ayoung: twitter?.... :(
18:44:34 <topol> ayoung, really???
18:44:47 <ayoung> atiwari, in the policy session, I think
18:44:49 <topol> that wasnt in my brochure
18:44:58 <atiwari> ok
18:44:58 <morganfainberg> jamielennox, welcome to the new internet
18:45:01 <ayoung> topol, according to the CDC
18:45:08 <dolphm> atiwari: has there been disagreement on the approach?
18:45:12 <ayoung> get an appointment at a travel clinic.
18:45:18 <ayoung> AND EVERYONE CHECK YOUR PASSPORTS!
18:45:23 <atiwari> not yet :)
18:45:50 <dolphm> atiwari: then i don't think we need a session
18:46:04 <gyee> and bring enough cash to buy your way out if you wonder into the wrong hood :)
18:46:19 <atiwari> dolphm, I don't think someone has looked in to it yet :)
18:46:21 <dolphm> jamielennox: want to propose the second client session and break down the descriptions?
18:46:27 <ayoung> atiwari, that should be discussed here: http://summit.openstack.org/cfp/details/86  I think.  It is not Audit specific, but all of that is based on the policy mechanism
18:46:50 <topol> gyee, do you know where I can get Louis Vutton knockoff wallets? My mom keeps asking :-)
18:46:53 <dolphm> atiwari: i've had several people mention it actually
18:46:58 <morganfainberg> topol, lol
18:47:00 <stevemar> i think everyone seems to be fine with the sessions topics .. next topic?
18:47:03 <gyee> topol, I know a place
18:47:09 <dolphm> stevemar: ++
18:47:10 <dolphm> o
18:47:12 <ayoung> atiwari, I have, and, while I like the concept, I think only LDAP really has the mechanism to enforce an attribute level  approach.
18:47:14 <stevemar> ya know, before we get off-topic!
18:47:17 <topol> gyee++ hook me up
18:47:20 <stevemar> #topic Code reviews for icehouse blueprints
18:47:23 <dolphm> i'll follow up with people submitting sessions after the meeting
18:47:50 <stevemar> #link https://review.openstack.org/#/c/40692/ KDS service
18:48:17 <bknudson> Is this implementing a PKI server? Why wouldn't we use an existing one? If it's not PKI, why not use PKI?
18:48:19 <ayoung> dolphm, so different from the Grizzly Summit, when it was You, me and heckj doing all the sessions. I could get used to this level of participation
18:48:32 <ayoung> bknudson, long discussion on that
18:48:34 <jamielennox> bknudson: no it's symettric
18:48:35 <fabiog> guys, can we please move forward with the shared-secret?
18:48:39 <fabiog> #link https://review.openstack.org/#/c/46771/
18:48:39 <ayoung> not PKI, but symetric crypto
18:48:53 <stevemar> thanks fabiog, that is for shared secret?
18:49:02 <ayoung> sharing symetric keys for high through put messaging
18:49:03 <fabiog> stevemar, yes
18:49:10 <fabiog> I think we should be close on that one
18:49:17 <stevemar> yeah, we're close on it
18:49:18 <atiwari> ayoung, thanks. I think it not going to so complex to implement in Keystone (or Oslo) out of the box
18:49:22 <fabiog> I did all the requested changes so far :-)
18:50:11 <jamielennox> bknudson: there was much discussion over the design for KDS, eventually it went symmetric mostly for the speed
18:50:35 <gyee> ayoung, so once KDS is in, you expect default bind token?
18:50:46 <ayoung> fabiog, why should shared secret be stored in the clear?
18:50:55 <bknudson> I thought TLS/etc work by generating symmetric keys after PKI
18:50:58 <ayoung> gyee, completely different issues
18:51:00 <jamielennox> gyee: no KDS has nothing to do with binding
18:51:10 <morganfainberg> ayoung, http://summit.openstack.org/cfp/details/255  did I cover everything?
18:51:17 <ayoung> bind token will require Kerberos or X509 support on the remote services, so it will be a rolling implementation
18:51:20 <jamielennox> bknudson: it does
18:51:36 <jamielennox> bknudson: the KDS design tracks closer to what kerberos does
18:51:45 <gyee> but KDS an implementation of Kerberos no?
18:51:57 <jamielennox> gyee: no, just same principals
18:52:04 <ayoung> bknudson, that is at transport layer, which MQ can use, but this is end to end message validity and then possibly encryption
18:52:19 <ayoung> gyee, no, it is like Kerberos, but Kerberos does much more.
18:52:56 <ayoung> It would have been easier to user Kerberos but that was deemed to high a bar to set for OpenStack undercloud setup
18:52:59 <bknudson> and PKI is too slow for end-to-end message validity and encryption?
18:53:06 <morganfainberg> dolphm, if ayoung is happy with my edits it can be moved back to approved. [post meeting likely]
18:53:18 <dolphm> morganfainberg: ack
18:53:28 <ayoung> morganfainberg, looks good to me. dolphm +1
18:53:33 <gyee> bknudson, I was thinking SMIME
18:53:43 <ayoung> gyee, that is what we use for PKI tokens
18:53:45 <dolphm> morganfainberg: i didn't realize about the no edits policy, i'll review each individually as i schedule them
18:53:56 <ayoung> CMS is basically another term for SMIME
18:54:03 <gyee> ayoung, right, SMIME is for message security
18:54:14 <morganfainberg> dolphm, hehe. i wouldn't have guessed except it was the way it worked.  maybe you can edit them?  not sure.
18:54:30 <gyee> you mentioned securing MQ
18:54:37 <gyee> that's why I was thinking SMIME
18:54:57 <ayoung> bknudson, topic has been hashed over fairly thoroughly.  THere is an etherpad off the blueprint worth reading through
18:54:57 <jamielennox> bknudson: the other problem with PKI is we would have to manage all those certificates and do signing, revocation, updating etc
18:55:13 <stevemar> lets all take another look at fabiog shared secret, it's close to being done
18:55:14 <bknudson> why would we manage them? there's already tools for it.
18:55:21 <gyee> jamielennox, we are doing it for PKI tokens
18:55:25 <gyee> at least we should be
18:55:34 <jamielennox> gyee: no, in that case we only manage one cert
18:55:38 <jamielennox> the one that does the signing
18:55:43 <dolphm> p.s. i discovered this recently https://wiki.openstack.org/wiki/KeystoneUseCases
18:55:56 <jamielennox> this would need to manage a certificate for every host that issues a message
18:56:01 <stevemar> dolphm, wow
18:56:01 <ayoung> bknudson, https://wiki.openstack.org/wiki/MessageSecurity#A_Key_Distribution_Server_in_Keystone
18:56:18 <dolphm> that would be fun to version control
18:56:40 <stevemar> #topic open discussion
18:56:47 <stevemar> only a few minutes left
18:56:48 <dolphm> code review use case -> code review api (if necessary) -> code review implementation of new feature :P
18:56:54 <topol> dolphm isnt that way out of date
18:56:58 <dolphm> topol: very
18:57:23 <dolphm> based on what's written, i'm guessing it was from spring 2012
18:57:30 <dolphm> most of it, anyway
18:57:38 <dolphm> ~essex
18:57:54 <ayoung> predates me.
18:58:07 <topol> sounds about right. take it to the pawnstars show to get a history lesson on it
18:58:13 <morganfainberg> lol
18:58:16 <gyee> jamielonnx did someone request Keystone to run CA service from the ML?
18:58:20 <dolphm> i don't know how to get the history out of the wiki, if there is any
18:58:24 <jamielennox> dolphm, bknudson: i've added the strings only interface to API discovery, can you have another look: https://review.openstack.org/#/c/38414/
18:58:38 <stevemar> dolphm, i was trying to do that, but i think the wikis have migrated right
18:58:39 <jamielennox> everyone else as well ^ but we were discussion this yesterday
18:58:45 <ayoung> gyee, I think for a dev CA we can look into using certmaster
18:58:52 <ayoung> https://fedorahosted.org/certmaster/
18:59:12 <ayoung> wouldn't use it in production, I'd recommend dogtag for that
18:59:21 <jamielennox> gyee: it has been suggested in the past, i don't like it without a REALLY good reason
18:59:24 <bknudson> it would be interesting to have certmaster configured by devstack
18:59:31 <jamielennox> i'd prefer to see barbican do that
18:59:40 <ayoung> bknudson, we are working toward that, jamielennox and I
18:59:45 <bknudson> rather than pki_setup
18:59:47 <bknudson> and ssl_setup
18:59:57 <ayoung> bknudson, I want certmonger as the the essential piece
19:00:02 <stevemar> #endmeeting