18:00:39 <morganfainberg> #startmeeting Keystone
18:00:40 <openstack> Meeting started Tue Jan 13 18:00:39 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:43 <jamielennox> o/
18:00:44 <openstack> The meeting name has been set to 'keystone'
18:00:55 <morganfainberg> Good morning! Quick housekeeping.
18:00:58 <nonameentername> o/
18:01:12 <morganfainberg> Next week no irc meeting, mid cycle instead.
18:01:17 <breton> hello
18:01:39 <rodrigods> midcycle should have a hangout... just saying..
18:01:39 <morganfainberg> I will try and setup a hangout (Google) for one of the days to get folks not in San Antonio involved
18:01:43 <rodrigods> yay
18:01:50 <raildo> \o/
18:01:52 <morganfainberg> But no guarantees it'll work.
18:01:57 <gyee> \o
18:02:15 <jamielennox> morganfainberg: would be appreciated
18:02:24 <topol> o/
18:02:33 <morganfainberg> If you haven't voted on the board of directors and bylaws changes. Go do it.
18:02:36 <gyee> morganfainberg, turns out monday is MLK holiday
18:02:44 <henrynash> hi
18:02:47 <morganfainberg> It is really really important to get votes.
18:02:59 <stevemar> o/
18:02:59 <morganfainberg> gyee: working holiday for us! :P
18:03:00 <dolphm> yeah, we really need the voter turnout
18:03:16 <dolphm> gyee: oops
18:03:33 <amakarov> I'm a little lost: where is this voting?
18:03:38 <gyee> hahaha
18:03:40 <topol> gyee I've already booked my flight
18:03:49 <dolphm> amakarov: if you're a foundation member, you'll have an email with a personalized voter link
18:03:49 <morganfainberg> So please vote. If you are a foundation member and didn't get a ballot (and have been since July 20 2014) make sure you contact secretary@openstack.org for your ballot link
18:04:11 <dolphm> email subject is "OpenStack Foundation - 2015 Individual Director Election"
18:04:20 <morganfainberg> amakarov: if you joined the foundation on or before July 20, 2014
18:04:30 <morganfainberg> You should have gotten that email.
18:04:40 <amakarov> morganfainberg, dolphm ok, I'm too young ))
18:04:41 <topol> I missed it.  Are you recommending particular folks?
18:04:41 <dolphm> but it's not just a director election, there are proposed changes to the bylaws
18:04:51 <jorge_munoz> o/
18:04:57 <morganfainberg> Topol no, just go vote.
18:04:59 <topol> any recommended bylaw changes?
18:05:06 <joesavak> topol - lol
18:05:12 <topol> morganfainberg OK
18:05:15 <ayoung> Oh, is it that time already?
18:05:19 <gyee> topol, yes, yes, and yes
18:05:25 <morganfainberg> Read them, I won't recommend yes or no on any director or bylaw changes.
18:05:53 <morganfainberg> Big tent, lawyer count, and % of community for bylaw changes are he resolutions
18:06:58 <morganfainberg> #info vote on board of directors and bylaw changes if you are eligible.
18:07:15 <morganfainberg> #info Spec proposal deadline for keystone: feb 5
18:07:27 <morganfainberg> Get your specs proposed and approved.
18:07:36 <morganfainberg> Last bit of house keeping.
18:07:58 <morganfainberg> I'd like to propose a code-feature proposal freeze 2-weeks prior to k3
18:08:29 <morganfainberg> Meaning no feature code after that mark. Will help limit last minute breaking things before feature freeze
18:08:38 <morganfainberg> Any complaints or concerns?
18:08:47 <topol> sounds very good
18:08:51 <samueldmq> ++
18:08:52 <nonameentername> that sounds good to me
18:09:02 <raildo> sounds good to me
18:09:04 <amakarov> amakarov, ++
18:09:06 <henrynash> so it is a proposal freeze or an actual code freeze
18:09:09 <joesavak> so that's a code feature freeze and not a code feature proposal freeze, right?
18:09:15 <henrynash> ha!
18:09:20 <morganfainberg> henrynash: code freeze for new features.
18:09:25 <lbragstad> so we will officially enter bug mode two weeks before k3
18:09:30 <henrynash> ok
18:09:32 <morganfainberg> lbragstad: correct.
18:09:37 <lbragstad> joesavak: code freeze
18:09:44 <lbragstad> s/code/feature/
18:09:44 <joesavak> +1
18:09:59 <morganfainberg> It gives us a window to fix anything outstanding on features but limits rebase hell
18:09:59 <henrynash> +1
18:10:00 <gyee> I think Jenkins freeze happens 4 weeks before :)
18:10:09 <ayoung> I thought we were going to be more forgiving than that
18:10:18 <ayoung> we used to say "Milestone 2"
18:10:29 <ayoung> and with the spec adoption, I thought we were going with Milestone 3\
18:10:34 <morganfainberg> ayoung: we are now saying 2-weeks prior to hard feature freeze
18:10:53 <morganfainberg> Just so we can limt rebase hell and last minute "omg we broke everything"
18:11:07 <ayoung> morganfainberg, does that mean that the review must be submitted, or that the review must be accepted and merged?
18:11:15 <ayoung> cuz we have so little time and so much process
18:11:32 <morganfainberg> Must be gating or ready to gate. This is milestone 3
18:11:42 <morganfainberg> Not milestone 2
18:11:53 <ayoung> I understand
18:12:32 <ayoung> Heh,  you can't get anything through Gate during M3 week anyway
18:12:38 <morganfainberg> Basically get your code ready to merge by 2-weeks prior to feature freeze. If we get most stuff done there, we will have less headaches to fight the gate at 1day before m3
18:12:53 <morganfainberg> Exactly.
18:13:07 <morganfainberg> We can revisit next week on Monday.
18:13:12 <morganfainberg> On to topics.
18:13:27 <morganfainberg> #topic OS-INHERIT
18:13:33 <morganfainberg> henrynash: o:
18:13:37 <morganfainberg> O/ even
18:13:53 <henrynash> actuall I think samuel was rasing this one...
18:13:58 <morganfainberg> Ack, battery is about to die, running to my desk.
18:14:05 <morganfainberg> Ok samueldmq o/
18:14:07 <morganfainberg> :)
18:14:25 <samueldmq> hi :)
18:14:35 <samueldmq> so we have one proposal regarding role inheritance
18:14:56 <samueldmq> currently we have OS-INHERIT:inherited_to: ['projects']
18:15:19 <samueldmq> this is in the spec, but we have implemented as  OS-INHERIT:inherited_to: 'projects' (without list)
18:15:50 <samueldmq> but instead of just fixing the spec, I was thinking about removing inherited_to: ['projects'], and keep just inherited=True/False
18:15:52 <henrynash> (that’s what gets returned by list_role_assignments to indicated that an assigment is inherited)
18:16:15 <samueldmq> henrynash, ++
18:16:27 <samueldmq> or passed to list_role_assignments to apply filtering
18:16:44 <henrynash> so a little background for everyone
18:16:57 <bknudson> I think we need to go with changing the spec to match the code... openstack rules.
18:17:22 <gyee> why's there a list to begin with? we have something other than projects in mind?
18:17:26 <samueldmq> bknudson, yes, that would be the first step, to get consistency asap
18:17:29 <henrynash> if you remember when I first proposed inheritance from domain->projects we had a long debate about how “inheritanc” should work
18:17:51 <ayoung> make domain is-a project and that issue goes away
18:17:56 <gyee> if we don't have anything else, true/false make sense
18:18:00 <bknudson> I don't think we can go changing the spec to inherited=True/False since that's against the stability rules.
18:18:13 <morganfainberg> bknudson: ++
18:18:26 <bknudson> plus I think it's a poor design choice to use a boolean where a more descriptive string would explain things.
18:18:32 <samueldmq> bknudson, we don't even support role inheritance on the clients I think (will recheck)
18:18:33 <raildo> gyee: with domain is a project, we need to inehrited to - subdomains
18:18:52 <ayoung> so we update the spec to OS-INHERIT:inherited_to: 'projects'  right?
18:19:03 <amakarov> does it give any actual benefits?
18:19:03 <henrynash> at least one person was concerned that we might need more than just “inherit down the tree”..ans we might, in the future, want “directed inheritance”…i.e. OS-INHERIT: inherited_to : [“project_id”: 123, “project_id”:564]
18:19:05 <ayoung> I like that
18:19:11 <rodrigods> samueldmq, we don't
18:19:18 <samueldmq> rodrigods, thx
18:19:22 <rodrigods> the change to add support to inheritance in keystoneclient is under review
18:19:23 <gyee> henrynash, that's more flexible
18:19:29 <raildo> gyee: so I think that we need to create a  OS-INHERIT:inherited_to: 'domains' or something like that
18:19:41 <ayoung> raildo, nah
18:19:49 <ayoung> domain is-a project means we don't need it
18:19:51 <samueldmq> so since we don't even support role inheritance on the clients, and it's still an extension, I don't see a big concern on changing the API
18:19:55 <rodrigods> ayoung, ++
18:19:55 <ayoung> lets drive that one home instead
18:20:04 <gyee> domain -> special project
18:20:04 <morganfainberg> ayoung, i agree, if we push domains == projects, this issue goes away
18:20:20 <ayoung> morganfainberg, and we need to get that working for HMT anyway
18:20:26 <morganfainberg> ayoung, yes
18:20:49 <ayoung> raildo, and rodrigods are going to take a hack at it from my WIP
18:21:05 <henrynash> I personally think that anying other than “inheritance down the tree” plus teh ability of a node to block inheritance is about as much as any adminstrator will be able to cope with
18:21:06 <ayoung> henrynash, I like the  inherited_to : [“project_id”: 123, “project_id”:564]
18:21:07 <raildo> ayoung:but if I inherited a role in all subdomains, i broke the reseller, because a user in a parent domain can manager users in a subdomain
18:21:26 <samueldmq> henrynash, ++
18:21:52 <ayoung> Ah...
18:21:59 <samueldmq> raildo, that should be solved by what henrynash just proposed
18:22:07 <samueldmq> raildo, a flag to block inheritance
18:22:14 <ayoung> OS-INHERIT:inherited_to: 'not projects'
18:22:19 <ayoung> er
18:22:20 <henrynash> ayoung: so while directed inheritance sounds kind of cool…if you really had  complex usage model of that……would an admin have any clue what was going on?
18:22:22 <ayoung> OS-INHERIT:inherited_to: 'not domains'
18:23:03 <ayoung> henrynash, depends on the quality of the admin, as always
18:23:04 <bknudson> inherited_to would have to be a dict.
18:23:31 <amakarov> ayoung, may it be just omitted?
18:23:36 <ayoung> bknudson, we should be able to handle both a single value and a dict
18:23:42 <morganfainberg> an alternative would be to shelve OS-INHERIT and make inheritance a first-class part of the assignment api
18:23:47 <ayoung> amakarov, no,
18:23:53 <morganfainberg> OS-INHERIT would be maintained as is for legacy/compat
18:23:54 <gyee> things never change, people always fight over inheritance :)
18:23:59 <ayoung> amakarov, they need to say "inherited to projects that are not domains"
18:24:11 <samueldmq> #link the spec as it is today http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-inherit-ext.html#list-effective-role-assignments
18:24:19 <henrynash> this feels like a more complex topic given everyone’s views…sounds like we might want to have asession on this next week
18:24:26 <rodrigods> samueldmq, API spec
18:24:26 <amakarov> ayoung, reminds 'redelegation_count' :)
18:24:31 <morganfainberg> amakarov, yes.
18:24:45 <ayoung> amakarov, comparable, but different
18:24:48 <gyee> henrynash, ++
18:24:55 <dolphm> henrynash: +1 to all your comments here
18:26:03 <morganfainberg> if we do have directed sessions like that i'll work to make sure we have a hangout for those
18:26:07 <morganfainberg> as well.
18:26:14 <samueldmq> ++
18:26:16 <morganfainberg> esp since iirc samueldmq isn't there
18:26:16 <ayoung> the short, though, is that we should update the spec to match the code at a minimum, right?
18:26:31 <morganfainberg> ayoung, or ^^ my suggestion there [more work though]
18:26:48 <morganfainberg> ayoung, but the spec will need to match the code if we keep it in OS-INHERIT
18:26:53 <ayoung> morganfainberg, I think anythinig beyond what the code does today should be future work
18:26:56 <henrynash> ayoung: at a minimum, yes…
18:27:03 <morganfainberg> ayoung, correct
18:27:14 <morganfainberg> ayoung, minimum spec needs to match code 1st
18:27:26 <gyee> if we have to update the spec because of the code, the process is somewhat broken isn't it?
18:27:29 <ayoung> having them out of sync is problematic.  Since we have released code, lets agree to first update the spec, second solve the problem for the duration
18:27:38 <morganfainberg> gyee, some of this documentation was out of sync
18:27:40 <samueldmq> morganfainberg, so I'll submit a patch to fix the api spec
18:27:47 <ayoung> samueldmq, ++
18:27:50 <morganfainberg> gyee, this is a case where we keep contract with functionality
18:27:52 <samueldmq> morganfainberg, and then we decide further next week
18:28:01 <henrynash> gyee: well, only because we shipped that code 2 releases ago!
18:28:09 <gyee> oh
18:28:11 <morganfainberg> gyee, and ^^ what henrynash just said
18:28:15 * gyee stfu now
18:28:19 <morganfainberg> gyee, this is API spec not new-code spec
18:28:47 <dolphm> gyee: i wouldn't expect an unimplemented spec to be "final" until it has shipped as stable/*
18:28:49 <morganfainberg> #action samueldmq to update API spec to match actual code.
18:28:56 <morganfainberg> dolphm, ++
18:28:57 <dolphm> unimplemented api* spec
18:28:59 <ayoung> I know that Chadwick's new Postdoc is somewhere in Brazil, but I assume it is too much to hope he is anywhere near the rest of you guys, is it?
18:29:22 <rodrigods> yes
18:29:25 <morganfainberg> ayoung, lets discuss that in -keystone post meeting, we have a full agenda
18:29:32 <morganfainberg> moving on
18:29:35 <morganfainberg> #topic Multifactor Authentication
18:29:37 <gyee> dolphm, in that case, would it make send to write the code first, then change the spec
18:29:38 <morganfainberg> nonameentername, o/
18:29:48 <gyee> s/send/sense/
18:29:56 <nonameentername> o/
18:30:01 <morganfainberg> gyee, that is the point of the experimental -> stable workflow
18:30:05 <morganfainberg> gyee, for new stuff.
18:30:23 <morganfainberg> anyway, nonameentername floor is yours
18:30:39 <ayoung> morganfainberg, so with MFA, it seems like he first should be submitting a patch for OTP, no?
18:30:55 <nonameentername> I wanted to get some eyes and feed back on my spec.  It had a lot of possitive reviews but then died down
18:30:56 <morganfainberg> #link https://review.openstack.org/#/c/130376/
18:31:52 <morganfainberg> This is defintely on the list of specs to hit while at the mid-cycle, but i think most of the major concerns have been addrressed.
18:32:13 <bknudson> how does an auth plugin require another plugin (e.g., the otp plugin requires password plugin)?
18:32:19 <lbragstad> nonameentername: I know marekd had a bunch of questions before the holidays, but you addressed those?
18:32:32 <bknudson> also, should the otp plugin require password? what if I wanted to use something better?
18:32:50 <bknudson> oh, it's going to do both.
18:32:51 <gyee> where do we store the seed/secret?
18:32:56 <gyee> cred api?
18:32:57 <nonameentername> lbragstad: he wanted me to add api information, but I don't know if that belongs in the spec or if it should live in the identity-api project
18:33:12 <morganfainberg> bknudson, right now the architecture doesnt support requiring a plugin from another plugin, but a user can request multiple plugins
18:33:28 <bknudson> it would be interesting to see barbican integration with credentials.
18:33:38 <morganfainberg> gyee, i am pushing for barbican in general
18:33:44 <morganfainberg> as an option
18:33:58 <nonameentername> bknudson: yes, that is part of the spec
18:34:02 <jamielennox> bknudson: the v3 plugins are designed so that there can be multiple 'methods' just nothing uses it at the moment
18:34:04 <morganfainberg> bknudson, +∞
18:34:14 <bknudson> I thought we already had support for multi-factor authentication in the original auth plugin design.
18:34:24 <morganfainberg> bknudson, sortof.
18:34:30 <jamielennox> bknudson: you could write a plugin that essentially does multiple methods for you
18:34:34 <gyee> bknudson, this is the plugin itself
18:34:39 <gyee> not the framework
18:34:58 <nonameentername> gyee ++
18:35:03 <gyee> MFA can be implementd in so many ways
18:35:07 <morganfainberg> bknudson, nonameentername wants to enforce that in cases MFA is used [sometimes for all authentications], which today isn't there. no plugin for it.
18:35:12 <bknudson> if this is just proposing another plugin then that seems to be different than what the spec says.
18:35:46 <morganfainberg> bknudson, the spec is mostly implying a new auth-plugin
18:36:02 <gyee> password = pin + one time hash code
18:36:13 <morganfainberg> bknudson, but also proposing the framework change to allow a demand of multiple plugins for auth
18:36:17 <morganfainberg> bknudson, vs only on user request
18:36:36 <morganfainberg> bknudson, so you can say "user X must use MFA" vs "did user X use MFA"
18:36:37 <bknudson> gyee: is that how pam implements otp?
18:36:47 <morganfainberg> bknudson, depends on the OTP.
18:36:49 <nonameentername> morganfainberg: ++
18:36:50 <ayoung> so the question is whether the rule should be "no token without MFA"  enforced by auth pipeline  or "this API requires MFA" enforced by policy/
18:36:53 <gyee> bknudson, that's how google authenticator works afaik
18:36:57 <ayoung> the first is easier
18:37:07 <gyee> I had a prototype on that awhile back
18:37:09 <morganfainberg> ayoung, this is allowing for the first case
18:37:20 <bknudson> ok, I just wanted to understand it... I don't have a problem with the proposal.
18:37:22 <morganfainberg> ayoung, and providiung the plugin.
18:37:41 <morganfainberg> ayoung, the latter case is in the token-constraints type spec
18:38:08 <morganfainberg> ayoung, or part of policy language+middleware to expose
18:38:12 <morganfainberg> bknudson, ack
18:38:12 <jamielennox> so this is going to cause all sorts of problems with reauthentication
18:38:24 <gyee> reason I didn't propose the google authenticator change was that I was under the impression we are not going to do anything with IdP till we separate the identity piece from Keystone first
18:38:37 <jamielennox> it's not useful for any sort of automated service, are we mostly just considering horizon here?
18:38:45 <ayoung> auth pipeline right now is "or"  and this calls for "and"
18:38:45 <bknudson> jamielennox: good point... token only lasts 30 mins so I'll need to look at my keyfob again.
18:39:03 <morganfainberg> jamielennox, this is why it needs to be per-user. service users may not need/get it
18:39:05 <morganfainberg> jamielennox, MFA that is
18:39:22 <morganfainberg> jamielennox OR the service consumption would need to know how to do OTP for re-auth.
18:39:31 <bknudson> so then we also need a mechanism to store per user which auth is required.
18:39:34 <jamielennox> morganfainberg: right - didn't expect them to, i'm just wondering how the flow will work
18:39:36 <gyee> morganfainberg, right, MFA is generally bad for non-interactive users
18:39:48 <jamielennox> it also means that our clients need to start actually caching authetnication
18:39:50 <morganfainberg> jamielennox, please comment on the spec, that is where this should be defined.
18:39:54 <morganfainberg> jamielennox, ++
18:40:15 <morganfainberg> lets get the comments in order so we can get this landed monday/cleaned up ready on mondy
18:40:36 * topol just saw morganfainberg do +∞ and thought that is really cool
18:40:41 <morganfainberg> i think the major hurdles are solved in the proposal, now it's the "here are all the things that could be affected, lets not forget it"
18:41:32 <morganfainberg> as in the proposal is good. but we have associated functionality that would be impacted and can't be forgotten
18:41:42 <bknudson> use federation instead.
18:41:56 <dstanek> so does this mean that we are adding a per user auth column/table?
18:42:08 <ayoung> no
18:42:19 <ayoung> it should be on assignment, not on the user side
18:42:41 <gyee> dstanek, you don't need to, you can have policy around auth methods
18:42:47 <ayoung> specifically "in order to get a token for this role in this project, use needs to authentiate iwht F1, F2"
18:43:07 <dstanek> ayoung: that makes sense - so on a per assignment basis
18:43:55 <morganfainberg> dstanek, ayoung, i think that makes a lot of sense
18:44:01 <gyee> you can get a token with any method, but you may not be able to access certain apis with that method
18:44:06 <dstanek> i need to go back and read the spec again - it's been a while
18:44:09 <morganfainberg> lets comment on the spec.
18:44:15 <bknudson> with mod_shib can you put in a constraint on how the user authenticated?
18:44:19 <morganfainberg> we need to move on, still a lot to cover
18:44:27 <morganfainberg> bknudson, i think that falls into how the IDP auths
18:44:32 <nonameentername> thanks
18:44:34 <morganfainberg> bknudson, idp would enforce MFA or not
18:44:47 <morganfainberg> #topic Domain Config
18:44:48 <gyee> we need to cleanly separate out authn and authz
18:44:48 <ayoung> you could almost make it a property of the role
18:44:52 <morganfainberg> #link https://review.openstack.org/#/c/123238/
18:45:06 <morganfainberg> henrynash, o/
18:45:12 <henrynash> ok, so reminder on domain configs - this is to enable clouds admins to on-board a customer into a domain who has their own ldap settings...letting them doing it all via REST, rather than having to set up those hokey domain-specifc config files that I dreamt up a while back
18:45:24 <henrynash> intention is that we will deprecate the domain-specific config files, but still support for 2 release
18:45:25 <morganfainberg> henrynash, i support this change!
18:45:34 <henrynash> Most people seem OK on the spec, but wanted to see what the API might look like
18:45:40 <henrynash> so have prepared the simplest version: https://review.openstack.org/#/c/123238/10/api/v3/identity-api-v3.rst
18:45:54 <henrynash> but wanted to see what peopel thought about that vs alternatives
18:45:57 <ayoung> henrynash, you just inherited the hokyness from my LDAP config.
18:46:18 <henrynash> playing hokey was always good fun
18:46:18 <ayoung> that's what its all about.
18:46:19 <bknudson> I'm just glad we dropped XML support.
18:46:23 <henrynash> ha!
18:46:53 <henrynash> so the simpel proposal just puts the config as an attrivute in teh domain entity
18:46:59 <henrynash> feels a bit weird, but simple
18:47:00 <gyee> bknudson, not quite, SAML2 assertion
18:47:25 <ayoung> so...domain config in SQL by itself makes sense.  The question is does maintaining LDAP as a mapping separate from the way we do federation make sense?
18:47:27 <henrynash> alternative would be to perhaps suppost somthing a bit liek nova’s server details, i.e
18:47:34 <dolphm> henrynash: so, you're expecting ldap passwords and stuff to be in the API?
18:47:41 <henrynash> GET /domains/{domain_id}/config
18:48:05 <henrynash> dolphm: nice point
18:48:42 <gyee> may want to do another survey to see how many LDAP out there are password protected even for searches
18:48:45 <henrynash> dolphm: would have to be the encrypted version
18:48:49 <morganfainberg> gyee, surveys are sent.
18:48:59 <morganfainberg> gyee to all three MLs
18:49:01 <amakarov> henrynash, or template of some sort
18:49:07 <gyee> password protected LDAP searches specifically?
18:49:11 <morganfainberg> gyee, lets see how those retuern before asking about passwords
18:49:16 <gyee> k
18:49:17 <henrynash> ldap passowrds are ONLY reequired if anonymous searching is not supported
18:49:23 <morganfainberg> dolphm, this can also be brokered by credential/barbican
18:49:24 <amakarov> henrynash, with 'the stuff' to be inserted locally
18:49:33 <henrynash> otehrwise, no passwords needs
18:49:35 <gyee> I personally have not came across anything like that
18:49:40 <ayoung> gyee, we have to assume that there is a high lilkyhood that the user to do the LDAP query needs to be authenticated somehow
18:49:47 <morganfainberg> gyee, AD often does require bind to search
18:49:51 <gyee> ayoung, unlikely
18:50:09 <ayoung> gyee, its common to require some authentication
18:50:14 <ayoung> even if it is just a service user
18:50:26 <morganfainberg> gyee non-anon bind that is
18:50:34 <gyee> not for searches
18:50:37 <morganfainberg> something about SOCKS compliancy.
18:50:41 <ayoung> it was a requirement we had to implement in FreeIPA
18:50:42 <morganfainberg> gyee, yes. i've seen it.
18:50:52 <bknudson> I assume gyee is talking about large corporate directories... the one I know about doesn't require auth.
18:50:59 <morganfainberg> gyee almost every AD integration we did at metacloud needed a user/pass to bind for searches against AD
18:51:05 <dstanek> yes, happens all the time due to regulations
18:51:45 <gyee> SOX compliance?
18:51:47 <morganfainberg> in anycase henrynash, i think we need credential API support or barbican support for this.
18:52:05 <morganfainberg> SOCKS! toe socks comp... sorry i'll stop
18:52:08 <henrynash> so I had assumed we would use the same encyption technique taht we do in the config files.
18:52:14 <gyee> SUCK compliance :)
18:52:17 <gyee> SUCKS
18:52:37 <morganfainberg> henrynash, i think we should discuss this at the midcycle as well specifically on the security and password concerns
18:52:37 <henrynash> morganfainberg: meaning you store the ldap creds and then fill it in “on teh backend”
18:52:39 <bknudson> config files aren't encrypted
18:52:55 <henrynash> bknudson: but I think the password is, no?
18:53:02 <morganfainberg> henrynash, not really.
18:53:04 <dstanek> henrynash: when pulling out the config from SQL would you whitelist what can be return or blacklist passwords, keys, etc?
18:53:17 <gyee> obfuscated
18:53:46 <amakarov> gyee, not enough
18:53:47 <morganfainberg> dstanek, this is why i think it needs to go in credential or barbican - something we can be more watchful of
18:53:58 <dstanek> morganfainberg: ++
18:54:06 <henrynash> dstanek: we certainly could (in teh same way we do with the user record)
18:54:13 * morganfainberg comments on needing to "fix" credential
18:54:14 <ayoung> I think wee punt on this henrynash .  We kindof want to go a different way
18:54:29 <bknudson> since we can stick anything in credential or policy backend, put the config file in there.
18:54:30 <ayoung> And it avoids all these issues
18:54:31 <henrynash> ayoung: on which bit?
18:54:38 <gyee> amakarov, did oslo.config have the secured option?
18:54:44 <morganfainberg> bknudson, that might be the easiest solution
18:54:45 <ayoung> if we say "non trivial LDAP is done using SSSD and Federation"
18:54:52 <morganfainberg> ayoung, that is a separate discussion
18:54:58 <morganfainberg> ayoung, but related
18:55:06 <lbragstad> gyee: what's your definition of secured?
18:55:06 <ayoung> morganfainberg, it is an argument against his proposal
18:55:08 <morganfainberg> this is something we'll need to discuss at the midcycle.
18:55:16 <bknudson> oslo.config has a secret=True option but that just means it's not printed out when debug the config.
18:55:16 <ayoung> and I don't want to just say "no" without explaining why
18:55:20 <morganfainberg> we have 5 mins, so lets table
18:55:24 <morganfainberg> and discuss next week
18:55:28 <amakarov> gyee, don't know
18:55:33 <ayoung> ideally, LDAP would be just another form of Federation
18:55:38 <henrynash> ok, sounds like yamd (yet another midcylce discussion)
18:55:54 <morganfainberg> krykowski, o/
18:56:04 <krykowski> hi :)
18:56:06 <morganfainberg> #topic Keystone upgrades implementation status and known problems
18:56:09 <gyee> lbragstad, I thought oslo.config have an secured property for a config option, no?
18:56:14 <krykowski> I wanted to ask if Keystone is going to adopt oslo.versionedobjects? any status on that?
18:56:15 <morganfainberg> this is short i know, but wanted to get you a couple minutes
18:56:26 <morganfainberg> krykowski, not in kilo
18:56:46 <morganfainberg> krykowski, but i'd like to see it on the table and evaluated for L.
18:56:50 <krykowski> are there are plans for it to land? a spec for example?
18:57:05 <morganfainberg> krykowski, no spec yet. there hasn't been any real discussion on it
18:57:40 <krykowski> got it, you probably seen that there is already a spec in Heat to adopt this, to be ready to handle such updates
18:57:45 <krykowski> #link http://specs.openstack.org/openstack/heat-specs/specs/kilo/versioned-objects
18:57:47 <morganfainberg> i'd be happy to see some discussion occur in #openstack-keystone on it (please come and bug us!) so it can be made a priority/or determine why it wont work for L-cycle
18:57:59 <morganfainberg> in keystone
18:58:10 <gyee> ayoung, if we use SSSD, we have to make CMS a hell lot easier
18:58:21 <gyee> unless SSSD can dynamically reload the config files
18:58:33 <morganfainberg> henrynash, we can also continue discussion on it in -keystone today/this week
18:58:36 <ayoung> gyee, heh...exactly what I was wondering myself.
18:59:04 <morganfainberg> krykowski, so i think the option is there, but it wont happen in Kilo, if we have the discussion now we can prioritize for L
18:59:10 <morganfainberg> krykowski, is the answer to your question
18:59:11 <henrynash> morganfainberg: yep, good…tomorrow..for me
18:59:29 <morganfainberg> ok last thing to be said
18:59:30 <dolphm> krykowski: are you asking if keystone would approve use of oslo.versionedobjects, or asking for a volunteer to implement it?
18:59:55 <krykowski> I'd like to submit some spec for it for further discussion (event if occur in L-release)
19:00:01 <morganfainberg> ++
19:00:20 <morganfainberg> krykowski, we would need someone to help with the impl. on it / drive it
19:00:24 <morganfainberg> anyway we're out of time.
19:00:30 <morganfainberg> Last note:
19:00:46 <morganfainberg> please do bug triage! ( lbragstad has been doing it, some more eyes would help)
19:00:56 <morganfainberg> further talk on all topics in -keystone channel
19:00:58 <morganfainberg> #endmeeting