18:02:28 <dolphm> #startmeeting keystone
18:02:29 <openstack> Meeting started Tue Feb 25 18:02:28 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:30 <shardy> o/
18:02:31 <fabiog> o/
18:02:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:33 <ayoung> \m/    _v_    \m/
18:02:34 <openstack> The meeting name has been set to 'keystone'
18:02:41 <dolphm> https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:48 <dolphm> #topic Reminder: Icehouse feature freeze March 4th (features must be merged)
18:02:48 <fmarco76> \o
18:02:52 * lbragstad likes henrynash's spirit
18:03:03 <henrynash> :-0
18:03:03 <henrynash> :-)
18:03:40 <dolphm> we look to be still on a good velocity -- although there are few patches that haven't seen as many revisions as they should be getting in response to reviewer feedback
18:04:09 <dolphm> so if you have something in review with -1's, keep posting revisions ASAP :)
18:04:34 <dolphm> #topic Deprecate XML in Juno?
18:04:40 <dolphm> bknudson: o/
18:04:48 <ayoung> 1 week
18:04:48 <dstanek> dolphm: are some of those outside of the core team?
18:04:49 <ayoung> 7 days....168 hours  10080 minutes....604800seconds
18:04:49 <ayoung> AAAAH!
18:05:09 <bknudson> deprecate XML was mentioned on the mailing list recently with nova.
18:05:16 <bknudson> nova has deprecated it
18:05:19 <dolphm> dstanek: yeah
18:05:30 <dolphm> bknudson: for icehouse, correct?
18:05:34 <dolphm> to be removed in juno
18:05:39 <bknudson> so I think keystone is the only project that has it and hasn't deprecated
18:05:42 <morganfainberg> if the general direction is to remove XML support, i see no reason to not deprecate it in Keystone.
18:05:50 <dolphm> morganfainberg: ++
18:05:50 <jamielennox> bknudson: i completely agree that it's a good idea - the XML interface is dodgy at best, but nova is proposing that they do it with a new major version
18:05:56 <dolphm> we should at least be on the same deprecation timeline
18:06:00 <bknudson> dolphm: yes, they deprecated xml for icehouse -- their v2. and they have a v3 api that will not support XML
18:06:02 <morganfainberg> I don't know any deployments that use it (i've been listening)
18:06:08 <morganfainberg> everyone uses json afaict
18:06:32 <morganfainberg> it would also simplify things a good deal.
18:06:37 <bknudson> ok, just wanted to bring it up and see if there were any objections.
18:06:54 <jamielennox> isn't it a compatability issue to remove it for an existing API?
18:07:06 <ayoung> post to openstack mailing list on that one
18:07:13 <jamielennox> (my general feeling otherwise is good riddance)
18:07:14 <morganfainberg> jamielennox, if we do the 2 cycle thing, we probably can get away with it.
18:07:27 <dolphm> jamielennox: that's a good question - but we wouldn't be breaking that by deprecating it -- only be removing it
18:07:32 <morganfainberg> ayoung, ++ post to -operators and xposted to -dev would be good
18:07:44 <dolphm> deprecation at least discourages further wasted dev cycles on it
18:08:02 <morganfainberg> dolphm, bknudson , how good is the XML support in V3?
18:08:04 <morganfainberg> i... am embarassed i've never looked
18:08:12 <ayoung> dolphm, I thik the long term solution for keystone needs to be using Pecan'
18:08:15 <ayoung> s rending
18:08:16 <dolphm> morganfainberg: it works, that's about it
18:08:16 <bknudson> morganfainberg: for us it's just a translation layer
18:08:28 <ayoung> or whatever it is  that does the multiple content types
18:08:32 <morganfainberg> ayoung, ++ pecan
18:08:34 <morganfainberg> ayoung, yeah
18:08:37 <morganfainberg> dolphm, k.
18:08:59 <ayoung> I suspect that Pecan is going to change the output of the documents
18:09:06 <dolphm> pecan would try to expose a whole new API though, so that would be massively breaking without a lot of dev effort
18:09:12 <ayoung> cuz, you knowm, automated rendering and all
18:09:13 <dolphm> ayoung: ++
18:09:32 <morganfainberg> ayoung, we'll have to cross that bridge when we start down that path
18:09:34 <jamielennox> ayoung: it shouldn't change much in terms of output at all
18:09:53 <jamielennox> see: https://review.openstack.org/#/c/65428/
18:10:03 <jamielennox> (which was passing)
18:10:10 <jamielennox> #link https://review.openstack.org/#/c/65428/
18:10:29 <ayoung> jamielennox, is that rendering responses that used to be rendered with the XML middleware?
18:10:56 <jamielennox> ayoung: it force renders everything into JSON and then lets the XML middleware do its thing for now
18:11:12 <ayoung> jamielennox, that is what we are doing now anyway
18:11:16 <dolphm> just to get something in review to deprecate XML: https://review.openstack.org/#/c/76301/
18:11:19 <jamielennox> I was going to look at an xml rendererer for pecan later
18:11:27 <ayoung> so it is not using the Pecan XML renderer.
18:11:30 <jamielennox> ayoung: no
18:11:31 <morganfainberg> dolphm, snuck soemthing onto the end of the agenda, just for a quick status update
18:11:44 <dolphm> morganfainberg: ack
18:11:45 <dhellmann> you guys aren't using wsme for xml?
18:11:48 <jamielennox> ayoung: there isn't really a pecan renderer, there is a wsme xml renderer
18:11:51 <ryanpetrello> FYI, pecan doesn't have an XML renderer by default
18:11:55 <ryanpetrello> right, what jamielennox said
18:11:55 <ayoung> right, right
18:12:11 <ayoung> "or whatever it is  that does the multiple content types"
18:12:11 <jamielennox> dhellmann: we can't regarding the issue of having arbitrarty API inputs that i raised on the dev list a while ago
18:12:15 <dolphm> wsme is the interesting part of pecan/wsme
18:12:24 <dhellmann> jamielennox: right, ok
18:12:37 <morganfainberg> dhellmann, jamielennox, that is on the agenda to talk about for Juno ("extra" attributes)
18:12:48 <dhellmann> we're looking into ways to deal with that, since apparently every openstack API needs it
18:12:56 <jamielennox> dhellmann: i had a patch that would fix the problem for json, but i couldn't figure out a way to allow the same functionality for XML
18:12:57 <dolphm> dhellmann: really?
18:13:01 <morganfainberg> dhellmann, jamielennox, at least as far as i am concerned
18:13:13 <dhellmann> dolphm: yeah, jd__ is looking into the issue
18:13:14 <dolphm> morganfainberg: ++
18:13:31 <dolphm> need to start making a list of likely summit sessions
18:13:34 <morganfainberg> jamielennox, <xtra attr, name="thing" value="val" />
18:13:44 <dhellmann> s/every openstack api/far more openstack apis than I expected/
18:13:51 <morganfainberg> jamielennox, don't get too complex w/ it.
18:14:07 <morganfainberg> but likely the attrs would still need to be defined
18:14:22 <morganfainberg> i know that isn't valid xml.
18:14:31 <morganfainberg> dolphm, ++
18:14:32 <jamielennox> morganfainberg, dhellmann: it's fine for JSON because you can just parse direct to python, you could probably do the same thing for pecan's XML format but keystone wouldn't use that anyway - cause we're different
18:14:47 <dhellmann> everyone is a snowlfake
18:14:50 <dhellmann> er, snowflake
18:15:01 <morganfainberg> dhellmann, flowerflake?
18:15:10 <ayoung> dolphm, I suspect the buckets from last summit will stand as placeholders for the current summit:  client, federation, and so on
18:15:15 <jamielennox> it appears my wsme patch is on my work computer...
18:15:26 <dolphm> ayoung: that'd be a good start
18:15:38 <dolphm> ayoung: we'll likely have a slot or two less though
18:15:58 <ayoung> dolphm, only one session for Federation instead of two, then
18:16:04 <morganfainberg> dolphm, we did very well with unconfrence-like stuff.
18:16:09 <morganfainberg> dolphm, i think we can make up the difference
18:16:20 <dolphm> morganfainberg: and we'll do better with that this time around, if the logistics work out
18:16:32 <morganfainberg> dolphm, ++
18:16:32 <dolphm> --no-promises
18:16:38 <dolphm> #topic Fixing multi-backend LDAP with composite user/group IDs
18:16:45 <dolphm> morganfainberg: o/?
18:16:46 <henrynash_> so
18:16:59 <dolphm> henrynash_: my second guess
18:17:02 <morganfainberg> dolphm, henrynash_ ^
18:17:10 <henrynash_> this is just an update on this one….it's up for review
18:17:13 <ayoung> henrynash_, my big question is whether we "flip the switch" on the format by default
18:17:30 <henrynash_> #link https://review.openstack.org/#/c/74214/
18:17:48 <dolphm> henrynash_: that is an absolutely GIANT patch to land after feature freeze
18:18:00 <henrynash_> ayoung: agreed…and I think you are right, we should not flip the switch
18:18:24 <ayoung> dolphm, yeah, but it is a lot of repeated code in Id generation
18:18:53 <ayoung> roughly half is in tests...
18:19:08 <henrynash_> dolphm:yeah, a lot of the changes are where we generate a uuid in testing, we now call a method to do it
18:19:13 <ayoung> and he's written a lot of good text documentation
18:19:34 <ayoung> https://review.openstack.org/#/c/74214/12/keystone/identity/core.py  is mostly docs  and it is the large changed file
18:19:41 <ayoung> (outside of tests)
18:19:46 <henrynash_> ayoung: agreed
18:20:21 <morganfainberg> so... you're saying it's a config option to enable the "new" format?
18:20:37 <dolphm> let's try to get it in before next tuesday - if it doesn't land, my instinct is to hold it for juno rather than to land it as a "bug" fix
18:20:41 <ayoung> morganfainberg, I think so
18:20:43 <henrynash> morganfainberg: so for SQL new entities are in the new format always
18:20:50 <morganfainberg> henrynash, ok
18:21:01 <morganfainberg> henrynash, that was what we talked about, i'm cool w/ that approach
18:21:04 <morganfainberg> henrynash, :)
18:21:11 <henrynash> morganfainberg: but old-style UUIDs are still supported
18:21:15 <morganfainberg> henrynash, ++
18:21:17 <ayoung> yeah...larger Database columns, basically maxing out what we can fit in an "in line" text field.
18:21:18 <morganfainberg> henrynash, perfecrt
18:21:34 <henrynash> the config switch is for existing LDAP-as-the-default-domain installations
18:21:42 <morganfainberg> henrynash, 100% ++
18:21:50 <ayoung> We'll try to hit some live testing on this.  I think nkinder and company will be interested
18:22:24 <bknudson> I get this: Continue since identity does not exist.
18:22:27 <dolphm> henrynash: one of the docs refers to the "internal" format of ID's -- are you not proposing to change the ID exposed to the API?
18:22:31 <morganfainberg> henrynash, cool. yeah i just didn't want SQL stuff to end up not getting the new format for new entries
18:22:51 <ayoung> dolphm, format for ID has always been a blob
18:22:59 * ayoung wonders if we are going to break the other services
18:23:11 <henrynash> dolphm: not exitsing entity's ID will change
18:23:15 <dolphm> ayoung: if you're going to stop responding to existing ID's, that's likely
18:23:15 <morganfainberg> ayoung, hm. possibly
18:23:18 <ayoung> does Nova have an assumption of a uuid for a userid?
18:23:30 <ayoung> Yeah, we need this to be "actively enable"
18:23:32 <morganfainberg> ayoung, no.
18:23:33 <morganfainberg> ayoung, but might have a size expectation
18:23:41 <henrynash> dolphm: no….all existing IDs are still supported. period.
18:23:42 <ayoung> right...that is what I meant
18:23:51 <morganfainberg> ayoung, actually
18:24:02 <morganfainberg> ayoung, i don't think it wont matter.
18:24:05 <morganfainberg> ayoung, arg, s/wont//
18:24:09 <ayoung> double negative?
18:24:41 <jamielennox> ayoung: if we're unsure of things like other services size limits it seems like something we should hold until juno
18:24:42 <henrynash> dolphm: nobody;s existing ID will change (assuming we set the config switch the right way for people who have an LDAP as the default domain)
18:24:43 <morganfainberg> ayoung, no lose the second negative.
18:24:48 <ayoung> morganfainberg, the other projects store "owner" and might have fixed sized fields.
18:25:02 <morganfainberg> ayoung, i think only swift could care
18:25:08 <morganfainberg> ayoung, afaik nova cares about project
18:25:14 <ayoung> although...would tempest catch that?
18:25:15 <morganfainberg> ayoung, not "user" in that regard
18:25:48 <dolphm> morganfainberg: what about quotas?
18:26:01 <morganfainberg> dolphm, in nova, thats still project based
18:26:06 <morganfainberg> dolphm, not user based
18:26:18 <dolphm> good to know - i thought it was both
18:26:23 <morganfainberg> i'm 2x checking
18:26:30 <ayoung> dolphm, lets just assume it will break "somewhere" and make it an option that has to be actively enabled, and then we can chase down the offenders over time\
18:26:31 <dstanek> this sounds like a topic for the dev list to get a wider audience
18:26:32 <morganfainberg> actually
18:26:51 <dolphm> henrynash: has this been on list before?
18:26:58 <ayoung> Marconi, DBaaS, Barbican...who knows what evil lies in the hearts of code of men?  The shadow
18:27:04 <ayoung> and by The Shadow, I mean not us.
18:27:28 <henrynash> dolphm: so myself and ayoung have discussed the ideas of composite IDs (which is what this is) before on the list...
18:27:40 <ayoung> yep...got a lot of feedback, too as I recall
18:28:22 <morganfainberg> i'll grab nova folks and talk to them today about user id lenfth etc
18:28:23 <dstanek> henrynash: was the change is size called out at all?
18:28:24 <dolphm> henrynash: all i was going to suggest is to resurrect the existing thread
18:28:30 <bknudson> we're going to have some funny-looking ids for federation.
18:28:32 <morganfainberg> later today in our channel
18:29:27 <henrynash> dolphm: not a bad idea and make an explicit request on the size (dstanek - it was proposed as composite of two existing UUIDs)
18:31:07 <ayoung> its not just nova I am worried about.  Nova would get caught in Tempest testing
18:31:33 <bknudson> tempest hasn't been complaining so far
18:31:37 <morganfainberg> well i think it wont be a huge issue but we'll 2x check.
18:31:48 <dolphm> ++
18:31:49 <dolphm> #topic v2 tenant list
18:31:51 <dolphm> henrynash: o/
18:31:56 <ayoung> bknudson, question is whether tempest is running against MySQL.  If so, we are getting out length checked
18:32:11 <bknudson> ayoung: tempest runs mysql and postgres
18:32:14 <dolphm> henrynash: i could probably address this topic as well
18:32:15 <henrynash> so just a quick one on tenant list
18:32:34 <henrynash> dolphm:ok
18:32:34 <ayoung> bknudson, yeah, so we should be good, since tempest was run by check on henrynash 's patch
18:32:37 <bknudson> we could return 2 tenants with the same name.
18:32:54 <henrynash> bknudson: yep
18:32:56 <bknudson> I ran the db2 migrations and no complaints.
18:33:02 <dolphm> henrynash: the only intended purpose for the default domain is to provide domain-scope for domain-unaware v2 calls (which is all of v2)
18:33:02 <morganfainberg> henrynash, yes V2 should only show default domain.
18:33:23 <dstanek> so, with this change are all user ids larger than the previous max?
18:33:33 <dolphm> henrynash: so users and tenants should only ever be returned from the default domain in v2
18:33:37 <morganfainberg> dolphm, ++
18:33:38 <henrynash> dolphm: that's my view too…and in fact we do restrict it for users (slight by mistake)
18:33:56 <dolphm> henrynash: by mistake?
18:34:20 <bknudson> what if you get the projects for a user...
18:34:28 <bknudson> and the projects are not in default domain.
18:34:32 <bknudson> I don't know what all the operations are.
18:34:35 <henrynash> dolphm: my original changes to multi-backend for Havana caused the user list via v2 to only be for the default domains
18:34:40 <dolphm> bknudson: it should only show tenants from the default domain
18:34:44 <dolphm> if you're making that call on v2
18:34:58 <ayoung> ++
18:35:01 <dolphm> henrynash: that's perfect
18:35:02 <morganfainberg> we should do filtering to eliminate V3 specific data
18:35:08 <morganfainberg> henrynash, ++
18:35:09 <dolphm> henrynash: and should have been the existing behavior if it wasn't :(
18:35:15 <ayoung> henrynash, it might not have been intentional on your part, but it was right
18:35:15 <henrynash> dolphm: yep
18:35:43 <henrynash> but I never touched projects, hence it has the old behavior
18:35:46 <gyee> ++
18:36:10 <henrynash> it's an easy one-line fix (plus some testing) so can submit a patch for review today
18:36:32 <morganfainberg> henrynash, can you also ensure other V3 specific data doesn't get returned (e.g. projects for user)
18:36:33 <morganfainberg> ?
18:36:34 <gyee> v2 API have no access of projects and users outside of the default domain
18:36:38 <morganfainberg> henrynash, or is that a larger scope
18:36:50 <morganfainberg> and/or needs more time/energy/resources to complete
18:37:17 <henrynash> morganfainberg: yeah, I wondered about that….I think it probably IS possible that there are holes there
18:37:40 <gyee> we have those filters in place already right?
18:37:45 <morganfainberg> gyee, not sure.
18:37:50 <morganfainberg> gyee, but we should
18:38:00 <gyee> I remember seeing them for the token APIs at least
18:38:07 <henrynash> I'll fix this specific issue (tenant list) as one patch…and investigate other issues sperately
18:38:12 <morganfainberg> henrynash, ok
18:38:14 <dolphm> henrynash: thank you!
18:38:34 <dolphm> #topic Kite
18:38:37 <dolphm> morganfainberg: o/
18:39:00 <dolphm> (this is also on the TC agenda for today)
18:39:09 <morganfainberg> dolphm, just a quick status update, (correct me if i'm wrong) we're waiting on TC meeting later today to know if we have scope increase for splitting the repos to openstack/kite
18:39:22 <ayoung> kite is for KDS only, right?
18:39:40 <morganfainberg> dolphm, talked w/ jamielennox, if the split doesn't occur i think the best bet is to remove KDS from the keystone repo before RC then add it back in post split.
18:39:44 <gyee> kite is KDS right?
18:39:45 <morganfainberg> ayoung, yes
18:39:48 <morganfainberg> gyee, yes
18:39:49 <dolphm> morganfainberg: so, if the TC views this as an increase of scope beyond our existing mission statement, then there will be a lot more discussion
18:39:54 <dolphm> morganfainberg: ++
18:40:08 <morganfainberg> sorry post RC cut
18:40:12 <morganfainberg> not split :)
18:40:19 <jamielen-> dolphm: this has been the problem in the past though, the reason it had to be in keystone repo to begin with
18:40:22 <bknudson> we'd have to drop kite entirely if TC doesn't like it?
18:40:23 <morganfainberg> so we don't halt development, but we don't release bad code.
18:40:26 <jamielen-> grr, stupid irc
18:40:28 <dolphm> i'd be fine with a repo on stackforge; it's obviously not going to be an integrated project as of icehouse
18:40:44 <dolphm> bknudson: the TC only cares about the proper program to govern the project
18:40:46 <morganfainberg> dolphm, sure i'll convert my patch to move it to stackforge if TC says no today
18:40:58 <dolphm> bknudson: i.e. whether kite falls under identity or not
18:41:16 <morganfainberg> dolphm, the goal is to not release anything in icehouse that is broken-non-functional
18:41:24 <dolphm> and the TC is going to discuss kite vs barbican, and i'm sure identity vs barbican as well
18:41:29 <dolphm> morganfainberg: ++
18:41:44 <gyee> if kite is identity then so is barbican :)
18:41:59 <jamielen-> morganfainberg: ++ i don't want what is currently KDS in icehouse
18:42:01 <morganfainberg> gyee, which isn't nessiciarly the wrong "program" for either
18:42:16 <morganfainberg> gyee, barbican and kite are not keystone and that is the important distinction
18:42:25 <gyee> morganfainberg, it all depends on the definition
18:42:51 <morganfainberg> gyee, i didn't say it was the "right" program, but it isn't the "wrong" program. they are (imo) separate projects
18:43:03 <dolphm> the scope of "identity" is defined here https://github.com/openstack/governance/blob/master/reference/programs.yaml
18:43:03 <gyee> in the upcoming summit, lets have a session on what exactly is Keystone
18:43:15 <dolphm> so it's up to the TC to determine of kite falls inside or outside of that scope
18:43:36 <morganfainberg> dolphm, yep. just wanted to make sure everyone was aware kds/kite will be out of the repo by RC
18:43:48 <dolphm> (i'm curious about everyone's opinions here, too)
18:43:50 <morganfainberg> it isn't ready and shouldn't be in keystone
18:44:24 <dolphm> morganfainberg: ++
18:44:42 <morganfainberg> dolphm, my opinion is that barbican (certs, keys, etc) same w/ KDS  are forms of identity. and should be in the identitty program
18:44:51 <ayoung> its undercloud identity management, out of the scope of keystone currently, but I think we need to loop back around on what is meant by Identity Management, and how Open Stack is approaching it for the Undercloud
18:44:52 <morganfainberg> dolphm, they should be separate projects
18:45:00 <dstanek> morganfainberg: ++
18:45:04 <jamielen-> dolphm: i'm happy to have it outside of keystone, but we're kind of back to where we were last summit - maybe it is, maybe it isn't, we put it in keystone because it was the quickest way
18:45:38 <ayoung> KDS provides an "identity" for invidual hosts inside of the undercloud that doesn't exisitng in a consistent way.   KDS, OTOH, only provides symmetric keys, which are not sufficient for Identity managment purposes, too
18:45:40 <morganfainberg> ayoung, i think Identity program should encompass cloud and undercloud (i hate "undercloud" as a term)
18:46:03 <mordred> morganfainberg: what's wrong with undercloud?
18:46:08 * mordred goes back to hiding
18:46:10 <morganfainberg> ayoung, but, as you are a fan of saying, if you squint hard enough...it looks like identity
18:46:13 <ayoung> morganfainberg,  KDS and certificate management are both part of Identity management
18:46:23 <morganfainberg> mordred, i dislike "cloud" as a term ;)
18:46:29 <mordred> morganfainberg: +100
18:46:32 <morganfainberg> mordred, i don't have an alternative
18:46:41 <ayoung> and we are going to be doing more certificate management as part of keystone.  We already distribute signing certs
18:46:44 <morganfainberg> ayoung, yes.
18:46:45 <mordred> morganfainberg: there are no alternatives - only worse words
18:46:55 <ayoung> Data center management
18:47:10 <morganfainberg> ayoung, ++
18:47:17 <gyee> ayoung, but Keystone is not issuing certs, yet
18:47:24 <jamielen-> ayoung: if so we should have barbican closer to keystone
18:47:29 <ayoung> gyee, nope, and I don't think it should isssue them
18:47:38 <ayoung> but distribution....
18:47:51 <morganfainberg> gyee, but i think cert issuance and distribution IS identity management
18:48:03 <gyee> morganfainberg, I am not disagreeing
18:48:08 <ayoung> the question is "OK I have a signed document. I know who signed it, but it has no cert embedded.  Where do I get it?"
18:48:31 <ayoung> and for messaging  (pub sub) we are going to need to use PKI, cuz symmetric won't cut it
18:48:40 <gyee> ayoung, ++ for PKI
18:48:46 <gyee> bout time!
18:49:03 <jamielen-> ayoung: i think that the 'no cert attached' thing is wrong and we only barely get away with it for tokens because of size
18:49:16 <ayoung> jamielen-, its a performance tune
18:49:24 <jamielen-> for tokens you should be syncing that cert around with puppet or whatever
18:49:27 <ayoung> jamielen-, with messaging, the constraints will be the same
18:49:41 <ayoung> no...puppet is the wrong tool for that
18:49:43 <jamielen-> the very nature of asking for a cert from someone else by name is wrong
18:49:47 <ayoung> fetch certs on demand
18:50:07 <gyee> ayoung, CMS/SMIME was for message security
18:50:13 <ayoung> jamielen-, the cert distribution can be as insecure as possible.  So long as the certs themselves are secure
18:50:30 <bknudson> if I wanted a cert I'd get it from LDAP
18:50:37 <bknudson> someone's public cert
18:50:42 <gyee> bkundson, cert lookup yes
18:50:48 <gyee> cert issuance no
18:51:03 <ayoung> bknudson, that is the solution of choice in the enterprise, yes
18:51:13 <bknudson> I don't think we need keystone to do cert issuance... solutions exist.
18:51:14 <ayoung> the underclopud does not disctate LDAP
18:51:30 <jamielen-> bknudson: ++
18:51:31 <morganfainberg> ayoung, but if the whole cert chain is insecurely distributed, how do you ensure you're getting the right authoritative certificate?
18:51:34 <ayoung> funny you should say that
18:51:35 <morganfainberg> ayoung, it's the idea behind trusting the root cert
18:51:54 <gyee> morganfainberg, cert fingerprint validation is out-of-band
18:51:56 <gyee> usually
18:52:07 <morganfainberg> gyee, you still need to trust the root cert
18:52:17 <ayoung> morganfainberg, yes, CA certs should be synced via Puppet, or something comparable
18:52:27 <gyee> morganfainberg, yes, but verifying the fingerprint of the cert you are importing
18:52:32 <morganfainberg> ayoung, ok cool as long as we're clear on that
18:52:33 <morganfainberg> ayoung, no problems :)
18:52:52 <morganfainberg> gyee, it isn't about importing the cert it's about management of the CA cert
18:52:56 <ayoung> keystone shipping the CA certs is suboptimal.  Its ok if you squint, but I'd prefer a better solution
18:53:07 <bknudson> ayoung: barbican?
18:53:11 <morganfainberg> gyee, we can't distribute the CA securely.. well we can but meh.
18:53:26 <gyee> morganfainberg, we do it via chef
18:53:31 <morganfainberg> gyee, it was just a point of "make sure we recommend how it's supposed to go"
18:53:32 <morganfainberg> gyee, yep
18:53:34 <morganfainberg> gyee, ++
18:53:37 <gyee> if you don't trust chef then there's no deployment :)
18:53:56 <dolphm> ayoung: shipping as in pki_setup? or shipping as in through the API/
18:54:09 <ayoung> bknudson, that is just pushing the responsibility around.  A CA cert should be a long term resource, should be signed buy, like, a verasign cert and so on, and should be verified by hand once in a while, too
18:54:31 <morganfainberg> gyee, not trusting your own CMS is not an OpenStack concern
18:54:38 <ayoung> I want pki_setup to go away...and I have a proof-of-concpet for that that aI am going to submit as a patch for devstack shortly
18:54:45 <dolphm> ayoung: yay
18:54:49 <morganfainberg> ayoung, double yay!
18:54:55 <dolphm> and ssl_setup
18:55:02 <jamielen-> ++
18:55:06 <ayoung> #link http://adam.younglogic.com/2014/02/certmonger-selfsigned-cms-cert/
18:55:37 <gyee> wait, you are replacing one *self-signed* with another?
18:56:16 <dolphm> gyee: i'm assuming self-signed there is just for the sake of a reproducible example (?)
18:56:25 <ayoung> gyee, only for development
18:56:42 <ayoung> gyee, the goal is to get certmonger in there, and have certmonger talk to the real CA
18:56:59 <gyee> k, I see
18:57:23 <ayoung> certmonger will talk to Barbican...or write your own CA plugin .  It can already do FreeIPA
18:57:42 <henrynash> dolphm: since we only have a minute of two to do, wanted to draw your attention to: https://bugs.launchpad.net/keystone/+bug/1284700
18:57:45 <ayoung> I discussed with the Barbican folks, they are on board
18:57:57 <jamielen-> we say all this but barbican currently has no PKI/cert abilities at all
18:57:57 <dolphm> and certmonger is in ubntu 13.10 now -- cool
18:58:17 <morganfainberg> and 14.04 is coming soon, so, new LTS!
18:58:17 <henrynash> dolphm: I just raised this…found it during testing for multi-backend….I'll be fixing that issue was well in a separate patch
18:58:28 <gyee> ayoung, nice! I think atiwari is also working on the PKI piece for barbican
18:58:32 <dolphm> henrynash: ack
18:58:39 <ayoung> gyee, very cool
18:59:02 * dolphm 1 min
18:59:15 <ayoung> gyee, one summit session needs to be around service, endpoint, and policy distribution
18:59:19 <jamielen-> (it annoys me that barbican decided on a different HTTP framework to _everyone_ else)
18:59:21 <ayoung> atiwari, 's issues
18:59:23 <gyee> dolphm when you are accepting proposal for the upcoming summit?
18:59:33 <gyee> the design summit I mean
18:59:37 <morganfainberg> gyee, they typtically go up once speaker stuff is done
19:00:01 <dolphm> gyee: that probably won't happen for another month
19:00:01 <morganfainberg> gyee, so probably in a couple weeks
19:00:15 <morganfainberg> or what dolphm said
19:00:20 <stevemar> once we're able to propose sessions, we usually go through them after a few weeks, and cut it down to however many spots we have
19:00:29 <dolphm> open in a couple weeks, closed in a monthish, i'm guessing
19:00:32 <dolphm> stay tuned to http://summit.openstack.org/
19:00:36 <gyee> dolphm, morganfainberg, cool, I'm making a list
19:00:48 <dolphm> stevemar: ++
19:00:48 <dolphm> #endmeeting