18:06:14 <stevemar> #startmeeting keystone
18:06:15 <openstack> Meeting started Tue Feb  3 18:06:14 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:06:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:06:18 <openstack> The meeting name has been set to 'keystone'
18:06:22 <morganfainberg> there we go
18:06:23 <stevemar> my bad
18:06:27 <henrynash> #link https://review.openstack.org/#/c/151939/
18:06:28 <bknudson> what's the topic?
18:06:52 * morganfainberg was off in LP release management zone and missed the alarm for the meeting
18:06:59 <henrynash> idea is to allow a cloud provider to disable the ability of clients to store extra attributes with their SQL entities
18:07:14 <joesavak> o/
18:07:18 <krtaylor> o/
18:07:24 <bknudson> is somebody asking for it?
18:07:24 <stevemar> #topic Allow disabling of SQL extra attribute storage
18:07:27 <henrynash> right now, people could be storing PII data….and the cloud provdier woulldn’t even know it
18:07:29 <topol> o/
18:07:45 <jamielennox> o/
18:07:56 <henrynash> we already (effectively) allow you to disable it with LDAP (since you have to provide a mapping)….
18:08:06 <henrynash> ..but for SQL, you can;t turn it off
18:08:18 <bknudson> I'd rather the identity backend went away
18:08:22 <bknudson> use federation
18:08:23 <henrynash> would be “enabled” by default, for backward compatibilty
18:08:40 <henrynash> this is also true for assignments and resources
18:08:47 <marekd> bknudson: ++
18:08:56 <rodrigods> federation ftw
18:08:58 <henrynash> bknudson: don’t disagree
18:09:06 <bknudson> I will disagree!
18:09:07 <topol> henrynash what is the advantage. When would you recommend to a stakeholder to turn it off?
18:09:16 <bknudson> j/k
18:09:31 <topol> I get the PII argument but are there others?
18:09:34 <henrynash> unless you know your clients are doing this, we would advsie them to turn it off
18:09:41 <gyee> henrynash, so we are going to disallow MacDonald to give out toys for kid meat because kids are getting fat?
18:09:43 <dolphm> so, you're mostly talking about extra user attributes?
18:09:44 <bknudson> off by default?
18:09:49 <henrynash> they could be storeing laubounded data sets
18:10:05 <topol> gyee only in your state :-)
18:10:07 <henrynash> #link https://review.openstack.org/#/c/151939/
18:10:23 <dstanek> henrynash: is this for only identity or for all of the models that use extra?
18:10:36 <morganfainberg> dstanek, i would like to see this for *all* models not just PII on user
18:10:53 <dolphm> morganfainberg: ++
18:11:07 <henrynash> dstanek: so I think we want to the option for all entities, I’m open if it needs to be a single flag, or one each or identity, assignment etc.
18:11:11 <dstanek> i don't think keystone should act as a cloud providers makeshift redis
18:11:14 <dstanek> morganfainberg: ++
18:11:17 <morganfainberg> dstanek, exactly
18:11:18 <jamielennox> it's always been something that i hated about our SQL backend, it'd be nice to remove the 'extra' with a view to deprecate it
18:11:19 <amakarov> so anything using extra is to be updated?
18:11:20 <bknudson> seems easy enough and it would help deployers be a bit more secure... hopefully it's implemented such that it's easy to maintain.
18:11:49 <henrynash> no changes to teh SQL models would occur this these proposal…we’d just disable the read/write of it
18:11:50 <jamielennox> also stick with a single for now and see if anyone wants in more granular
18:12:10 <dolphm> bknudson: i imagine all the existing code could still run, but if extra != '{}' on create or update then 400?
18:12:17 <henrynash> we’d leave it for out-of-band work for cloud provdier if they want to delete existing stored extra data
18:12:24 <amakarov> what profig gives 'extra' now and what do we offer instead?
18:12:40 <amakarov> s/profig/profit/
18:12:49 <bknudson> this might mess with our JSONSchema validation code.
18:12:50 <henrynash> dolphm: that was probably my only question…would we silently drop and extra data provdied, or error
18:13:14 <dstanek> error
18:13:15 <amakarov> henrynash, redelegation uses extra now
18:13:18 <jamielennox> henrynash: if it's opt in then i think drop is acceptable
18:13:20 <dolphm> henrynash: maybe that's a secondary option, but as a client i'd rather be alerted via 400
18:13:36 <gyee> if 'extra' is not in the spec, then its a fair game
18:13:39 <bknudson> the config option could be "drop", "error", etc.
18:13:55 <henrynash> bknudson: interesting….
18:14:09 <henrynash> gyee: extra has never been in the spec as far as I know
18:14:12 <morganfainberg> i *think* extra was in the spec somewhere.
18:14:13 <dolphm> henrynash: it's also easy to enable this with lbragstad's jsonschema work -- there's an any_other_attribute thing that's enabled somewhere
18:14:15 <topol> "i don't think keystone should act as a cloud providers makeshift redis" Great quote by dstanek!
18:14:16 <morganfainberg> but it wasn't pervasive
18:14:16 <dstanek> henrynash: does this only add a config option or are you thinking that we would actually remove the field using migrations?
18:14:30 <gyee> morganfainberg, was or is?
18:14:44 <dolphm> henrynash: i don't think extra is in the spec either
18:14:47 <henrynash> dstanek: just the config option….would not remove the SQL data
18:14:49 <dolphm> any spec
18:14:53 <lbragstad> henrynash: dolphm https://github.com/openstack/keystone/blob/master/keystone/assignment/schema.py#L39
18:14:54 <bknudson> if it's not in the spec then it's just behavior that we have to preserve.
18:15:04 <morganfainberg> topol, https://twitter.com/MdrnStm/status/562675595633774592
18:15:12 <dolphm> lbragstad: ++
18:15:17 <henrynash> bknudson: absolutely…we KNOW peopel do use it in some circumsatnces
18:15:18 <dolphm> bknudson: ++
18:15:23 <gyee> lets do this
18:15:29 <dolphm> henrynash: ++
18:15:34 <topol> morganfainberg LOL! Im retweeting
18:15:54 <morganfainberg> henrynash, metacloud made/makes extensive use of extra values
18:16:10 <morganfainberg> (cc cburgess ^ not sure if you're still doing that)
18:16:15 <henrynash> morganfainberg: which is why default option is no change
18:16:26 <cburgess> I'm here..
18:16:32 <cburgess> Yeah we still use extra values.
18:16:44 <bknudson> we could have a config option where you can provide extra jsonschema for each resource type.
18:16:44 <cburgess> We are still using the self service code you are familiar with.
18:16:46 <henrynash> long term, we want people to write out-of-tree extensions that catch notifications to store their own data
18:16:59 <stevemar> henrynash, i'm not seeing a lot of net positive in dropping the extra bits
18:17:38 <topol> for a hybrid cloud, if part has extrat atrib8utes enabled and part does not will interoperability be impacted???
18:17:50 <cburgess> Its probably not the end of the world for us if it goes away. Means we have to write our own migration for that data when we hit the cliff of its going away in the DB.
18:17:52 <morganfainberg> topol, not really
18:18:06 <henrynash> stevemar: long term, I don’t think we want keystone to be storing the data…we want peopel to extend keystone with tehir own code to store their own data…this is a first step on that path
18:18:06 <morganfainberg> extra values are *mostly* just redis with a bad name
18:18:11 <gyee> topol, if its not in the spec, then there's no interoperability concern
18:18:20 <bknudson> I also get concerned that we have all these config options that make their cloud work differently and who knows if anybody uses them.
18:18:21 <morganfainberg> henrynash, actually i'd go a step further - we don't want people to extend keystone
18:18:22 <cburgess> That being said I would prefer not to have to do extra work but we don't always get what we want.
18:18:29 <topol> morganfainberg, good. Was hoping that was the case. But had to ask. even if it involved the QOTD
18:18:39 <morganfainberg> i'd rather see that data be stored externally and referenced when needed
18:18:54 <stevemar> bknudson, yeah, agree with that
18:18:59 <gyee> morganfainberg, like roll your own damn IdP :)
18:19:02 <henrynash> morganfainberg: true…we want them to add theit own code that might inteact with keystone (via notifcations) if their data needs to be tied to keystone entiytes
18:19:04 <morganfainberg> it really isn't keystone's job to store "blob of whatever you shoved in"
18:19:05 <stevemar> default and deploy
18:19:08 <bknudson> the problem is developers wind up coding to the defaults.
18:19:17 <cburgess> morganfainberg: You are killing me here.... :P
18:19:20 <lbragstad> sounds like time for another survey!
18:19:35 <morganfainberg> cburgess, i am trying to make your life exciting!
18:19:44 <breton> how many people participated in the previous ones?
18:19:52 <morganfainberg> breton, exceedingly small numbers
18:19:59 <bknudson> it's not like we can stop deployers from disabling extras already... just edit the code.
18:20:01 <morganfainberg> the LDAP identity one had the best response.
18:20:23 <gyee> bknudson, we prefer monkeypatch
18:20:27 <henrynash> so all this proposal does is allow us to stop doing this, but the default is “current fucntionality”….is there any arguement at least about taking at least that first step
18:20:38 <morganfainberg> so - i think the right answer here is [unfortunately] not getting rid of extras short of a V4 API.
18:20:51 <morganfainberg> i would like an option to turn those off.
18:21:03 <morganfainberg> and/or look at moving the data into not being wedged into the model
18:21:28 <morganfainberg> but we wont ever (again short of API version) be able to rid ourselves of extra since it is an actively used feature
18:21:29 <gyee> ver ver ver v4!
18:21:31 <jamielennox> morganfainberg: v4 api will have the same issues where data would already be stored in extra and you have to choose how to represent it
18:21:47 <marekd> are there any plans fo v4 actually?
18:21:49 <morganfainberg> jamielennox, nope. part of the migration would be "extra doesn't exist, use something else"
18:21:53 <morganfainberg> marekd, no
18:21:56 <marekd> morganfainberg: ok.
18:21:58 <gyee> don't start no shit now
18:22:04 <morganfainberg> and i will go on record here and say not just no, hell no.
18:22:05 <dolphm> v5 ftw
18:22:08 <henrynash> morganfainberg: I agree….we can’t actually take away extra yet]
18:22:08 <jamielennox> morganfainberg: a new version is not a migration
18:22:09 <morganfainberg> but v5
18:22:16 <morganfainberg> jamielennox, yes it can be
18:22:19 <lbragstad> micro versioning!
18:22:23 <morganfainberg> jamielennox, feature X doesn't exist in new version
18:22:26 <morganfainberg> jamielennox, don't use it.
18:22:38 <dolphm> lbragstad: v2015.02.03
18:22:38 <morganfainberg> jamielennox, products do that all the time
18:22:43 <jamielennox> morganfainberg: not if v3 has taught us anything, if you don't provide what they want in v4 people will continue to use v3
18:22:51 <bknudson> let's all just forget that v4 ever happened.
18:22:53 <morganfainberg> jamielennox, but we're not doing v4
18:22:55 <morganfainberg> we're off topic
18:22:56 <jamielennox> we don't get to roll out a new server, v3 and v4 are just views onto the same data
18:23:13 <henrynash> ok, let’s decide on this one…and move on!
18:23:20 <morganfainberg> henrynash, we can't rid ourselves of extras
18:23:21 <bknudson> who's going to review it?
18:23:22 <morganfainberg> henrynash, sorry
18:23:24 <morganfainberg> we can make it better
18:23:30 <henrynash> all we are proposing here is: allow an option to disable storing it
18:23:37 <henrynash> not to remove extra
18:23:38 <morganfainberg> we can unwedge it from the models and we can allow people to disable it
18:23:42 <bknudson> if you can find 2 cores to review it then go ahead.
18:24:06 <jamielennox> henrynash: i'm good with it as an option that we can start pushing people towards
18:24:12 <cburgess> morganfainberg When you said unwedge what does that mean?
18:24:14 <morganfainberg> but as much as we hate it - it can't go away because it is being used. we might want to offer operators a way to define a schema for it
18:24:37 <morganfainberg> cburgess, right now extra is a json blob on say "user", make it not be an icky json bobl on the user row
18:24:47 <henrynash> morganfaiberg: you don’t think we can provide an option to disable yet?
18:24:57 <morganfainberg> henrynash, we can. but just expect no one to ever use it
18:25:00 <cburgess> How would data migrations work for that?
18:25:17 <topol> definitely cant take away. But can recommend you don't use
18:25:21 <dolphm> henrynash: do you have customers that would immediately use the feature?
18:25:23 <morganfainberg> cburgess, same way migration works today. doesn't change the API jsut how we store for more efficient use of storage
18:25:32 <cburgess> You want to just migrate the blob as it to another table and do a reference to it then?
18:25:45 <cburgess> Just trying to predict what a migration would look like for us.
18:25:52 <bknudson> so... one concern was already raised that we actually store real data in extras...
18:25:54 <dstanek> morganfainberg: sounds like a Keystone -> redis bridge - is that really what you want to do?
18:25:54 <dolphm> cburgess: that wouldn't solve henrynash's concern
18:25:55 <morganfainberg> cburgess, right now - no migration ;)
18:26:00 <bknudson> e.g., something with trusts and also email, etc.
18:26:01 <morganfainberg> dstanek, shhhh
18:26:27 <bknudson> I don't know what all might be in there
18:26:32 <henrynash> dolphm: not specific names ones…other than customer who are always asking “can I control whether PII info is stored"
18:26:35 <morganfainberg> bknudson, we should move all attributes we rely on / claim in the spec - as top level columns etc
18:26:39 <cburgess> So during an upgrade the deployers would have to have a script to do the data migration?
18:26:53 <bknudson> I don't want to rely on email.
18:26:53 <morganfainberg> cburgess, SQL migrate would handle if we did this
18:27:00 <cburgess> Ahh ok sorry was confused.
18:27:16 <gyee> cburgess, how can we migrate if we don't even know what's in extra?
18:27:31 <morganfainberg> bknudson, if it isn't part of the spec - it can shove it in extras - it is arbitrary data.
18:27:48 <stevemar> we're approaching the half way marker and there are 3 other topics, we should set time aside for those too
18:28:10 <henrynash> (and I thought this was an easy one!)
18:28:12 <morganfainberg> henrynash, i think the option is fine
18:28:12 <dolphm> morganfainberg: i'd rather just document a pair of queries - "what extra data is in my db?" and "delete all the extra data in my db" along with the option to prevent keystone from using extra any further
18:28:18 <cburgess> gyee That was kind of my point. If you go changing extras you have to migrate whats there as a blob because its completely unstructured from a keystone perspective today.
18:28:23 <bknudson> we can add comments to the spec.
18:28:38 <morganfainberg> just expect that no one will in practice use it. meaning there will be an edge case of customer who wants it
18:28:43 <morganfainberg> but most wont care
18:28:53 <morganfainberg> please move further comments to the spec
18:29:06 <bknudson> adding options that nobody can use just makes our job harder.
18:29:14 <gyee> cburgess, which mean its a mess any way you cut it :)
18:29:23 <morganfainberg> stevemar, next topic
18:29:28 <stevemar> #topic Email as a first class attribute
18:29:28 <bknudson> (like debug=False!)
18:29:34 <morganfainberg> gyee, cburgess, bknudson, please continue conversation on spec / -keystone channel post meeting
18:29:37 <henrynash> ok, now this one is contentious
18:29:45 <gyee> ++
18:30:08 <morganfainberg> henrynash, short - what is the usecase.
18:30:09 <dolphm> inverse of previous topic: promote PII to first class attribute
18:30:13 <bknudson> some people have multiple email addresses.
18:30:24 <dolphm> bknudson: most*
18:30:30 <marekd> ++
18:30:34 <morganfainberg> dolphm, everyone?
18:30:40 <stevemar> bknudson, dolphm but only one per domain
18:30:44 <morganfainberg> even my parents have more than one email each
18:30:55 <dstanek> i see the next topic is about a 1st class email, but we may also need to address any other data the Keystone stores in extra
18:31:08 <henrynash> morganfainberg: have requests from customer to “filter by email address”…where tehir users names are NOT email
18:31:18 <dolphm> dstanek: we're on that topic now
18:31:24 <bknudson> use ldap
18:31:37 <dstanek> dolphm: i know i typed that up and topol distracted me :-)
18:31:38 <morganfainberg> henrynash, i reaaaaaly don't want to make the SQL identity store more featureful unless we need to.
18:31:54 <gyee> you may have multiple email address, but are you allow more than one when you register with a cloud provider?
18:32:00 <henrynash> and right now we support email (or mention it in specs) a BIT….so we are bit conflicted…we need to push it one way or the other
18:32:03 <stevemar> dstanek, keep your head in the game
18:32:28 <morganfainberg> i kindof hate that we store any PII in keystone as part of the spec.
18:32:30 <jamielennox> henrynash: if it's mentioned in the spec it shouldn't be extra from the sense of disabling extra
18:32:32 <stevemar> henrynash, is the customer using sql or ldap?
18:32:37 <gyee> jsavak, does RAX allow multiple emails during registration? HPCS does not
18:32:55 <henrynash> stevemar: I don’t actually remember…but I think LDAP
18:33:00 <amakarov> 1 email as id per user instance is a common practice...
18:33:04 <dolphm> gyee: sort of?
18:33:11 <henrynash> stevemar: and our LDAP moduel DOES support email  address mapping
18:33:23 <jsavak> gyee - no we don't. We have a separate service for "contacts" outside of keystone for address, phone, email, etc
18:33:30 <morganfainberg> henrynash, we might as well make it consistent between backends. but ugh
18:33:38 <dolphm> jsavak: but there's also sub account or child accounts or whatever
18:33:48 <morganfainberg> dolphm, subaccount would be a separate account no?
18:33:51 <gyee> dolphm, but those are per account right?
18:33:55 <henrynash> morganfainberg: and I think some of examples in the API spec show email being returned !
18:33:58 <morganfainberg> meaning i email <-> i account
18:34:09 <amakarov> morganfainberg, ++
18:34:10 <dolphm> morganfainberg: yeah, it's basically separate users in keystone land (someone correct me if i'm wrong)
18:34:11 <jsavak> dolphm - correct - those are additional identities with less authorization to access to the same cloud-account's tenants.
18:34:25 <morganfainberg> henrynash, sure make it a 1st class column.
18:34:42 <morganfainberg> consistent between abckends and the spec
18:34:47 * morganfainberg cries a little.
18:34:53 <gyee> cries?!!
18:35:11 <morganfainberg> i wish email wasn't in the spec ;)
18:35:15 <gyee> but wait, are we going to encrypt it?
18:35:16 <jamielennox> it's mentioned from the shell when creating users as well
18:35:19 <bknudson> QQ
18:35:26 <gyee> its PII afterall
18:35:28 <morganfainberg> gyee, not my problem.
18:35:28 <dolphm> morganfainberg: i don't actually remember that landing
18:35:31 <stevemar> bknudson, oh thats great
18:35:38 <morganfainberg> gyee, :P
18:35:45 <gyee> morganfainberg, at least provide a hook to encrypt it?
18:35:55 <morganfainberg> dolphm, if it's in the spec (API) and supported we need to probably make it 1st order
18:36:04 <morganfainberg> if it's not in the spec we can make it disappear from examples
18:36:10 <henrynash> gyee: which is why the spec says it should be a) optional, and b) there should be a config option to disable its storage
18:36:10 * morganfainberg checks
18:36:16 <gyee> a plugin or some sort?
18:36:26 <amakarov> +1 to encrypting stored emails
18:36:39 <morganfainberg> yep
18:36:42 <morganfainberg> it's only in examples
18:36:47 <morganfainberg> we could make it all disappear
18:36:54 <gyee> henrynash, *optional* first class attribute doesn't sound right
18:37:02 <bknudson> so is the identity / SQL backend now open to any kind of changes?
18:37:02 <henrynash> morganfainberg: which is why I said we are “conflicted a BIT”…since it is not in the spec, but is in the exaples, the client and teh LDAP options
18:37:15 <dstanek> amakarov: if you encrypt the email you can't filter on it
18:37:15 <dolphm> gyee: like description?
18:37:17 <bknudson> I thought we rejected features for identity in the past...
18:37:21 <bknudson> e.g., password policy
18:37:21 <cburgess> If you encrypt email addresses please make that configurable so that "None" is a valid option.
18:37:23 <morganfainberg> bknudson, if we called it out as an attribute
18:37:34 <morganfainberg> bknudson, i was going to say we need to fix it
18:37:40 <gyee> dolphm, ah you're right
18:37:41 <morganfainberg> in this case i say we remove it from our examples
18:37:54 <bknudson> maybe this is a bug and not a feature?
18:37:56 <morganfainberg> keystone should not use pii.
18:38:03 <morganfainberg> bknudson, a doc bug it looks like now
18:38:09 <amakarov> dstanek, and if you not you risk to expose it to some smart guy with a spam cluster :)
18:38:09 <morganfainberg> i thought it was claimed as an attribute
18:38:11 <morganfainberg> i was wrong
18:38:20 <gyee> man this rabbit hole is getting deeper
18:38:22 <morganfainberg> henrynash, cc ^
18:38:25 <henrynash> morganfainberg: it is a VERY common user attribute for mapping from LDAP to corproate stores
18:38:35 <morganfainberg> henrynash, we should *not* be mapping email.
18:38:43 <morganfainberg> and we should remove it from our examples
18:38:47 <morganfainberg> but we can't break people
18:38:59 <morganfainberg> but the right answer is don't put PII in keystone.
18:39:15 <morganfainberg> soryr to flip, my mistake for thinking one thing about the spec vs reality
18:39:18 <amakarov> dstanek, it still possible to filter by encrypted email: encrypt and filter :)
18:39:26 <morganfainberg> amakarov, i don't want to layer that in
18:39:30 <morganfainberg> amakarov, at all
18:39:46 <morganfainberg> i'd rather go to the operators and say "sorry we can't support this" and take the flames/yelling
18:39:47 <amakarov> morganfainberg, I understand
18:39:54 <morganfainberg> than need to handle PII properly *in* keystone
18:40:08 <gyee> amakarov, its call homomorphic encryption I think
18:40:14 <amakarov> morganfainberg, mb as a hook?
18:40:17 <morganfainberg> if it was part of our spec "aka: user create . email address" as an attribute my stance would be we need it
18:40:18 <morganfainberg> amakarov, no.
18:40:19 <dstanek> amakarov: only if you are encrypting wrong and not using a salt or we would have to store all of the salts separately
18:40:25 <gyee> basically allow searches on encrypted fields
18:40:30 <bknudson> if operators shouldn't store PII in keystone then that should be documented somewhere...
18:40:35 <henrynash> morganfaiberg: so I’m actually OK with not stoting in SQL…but it is a very common requirement to map via LDAP….I just don;t think we can say, you can’t do that
18:40:35 <morganfainberg> bknudson, ++
18:40:56 <morganfainberg> henrynash, we should *not* break ldap, but we should document don't store PII in keystone and remove it from all the examples (email)
18:41:14 <morganfainberg> henrynash, and it should not be made first-order in sql.
18:41:37 <henrynash> morganfainberg: and the client?
18:41:39 <morganfainberg> henrynash, i would also document that using the email map is a bad idea. email == username makes it a different class of data
18:41:42 <jamielennox> does PII include name?
18:42:04 <gyee> jamielennox, depends on who you ask
18:42:17 <morganfainberg> jamielennox, i think we can fudge on name if needed - it's grey
18:42:37 <morganfainberg> henrynash, client should not specifically require/call out email but we can't break compat.
18:42:41 <bknudson> that's why I use a made-up name.
18:42:57 <amakarov> dstanek, agreed, I cant imagine filter with a salt...
18:43:05 <morganfainberg> bknudson, i KNEW your real name wasn't brant!
18:43:07 <jamielennox> bknudson: i wondered about 'brant'
18:43:25 <morganfainberg> henrynash, same deal as LDAP
18:43:36 <stevemar> bknudson, it's been brent this whole time
18:43:40 <morganfainberg> henrynash, don't remove it - but it shouldn't be called out as available specifically
18:43:48 <morganfainberg> or in examples
18:44:01 <henrynash> morganfainberg: ok…so only issue is filtering when using LDAP…I’ll think on that one…but otherwise we clean up examples etc.
18:44:17 <morganfainberg> henrynash, fix filtering in the filtering fix spec.
18:44:28 <stevemar> next?
18:44:30 <morganfainberg> henrynash, and we know SQL identity sucks on some filtering
18:44:36 <henrynash> argeed…ok, I yield teh floor!
18:44:41 <morganfainberg> stevemar, go go next
18:44:46 <stevemar> #topic Barbican backend for Keystone Credential API
18:44:52 <gyee> \o
18:44:57 <gyee> so two issues
18:45:04 <stevemar> gyee, arunkant ^
18:45:14 <gyee> 1) we need to pass the user token to barbican
18:45:22 <bknudson> this is another credential backend, in addition to what we have already?
18:45:30 <morganfainberg> gyee, yep, known workflow for *things* in OpenStack
18:45:34 <gyee> 2) we need individual user token for migration if we are going to support migration
18:45:48 <bknudson> do we need auth_token in front of keystone then?
18:45:49 <morganfainberg> gyee, no magic migration.
18:45:53 <gyee> bknudson, yes, use Barbican
18:46:23 <bknudson> I have no problem with this as long as it's optional... barbican isn't integrated.
18:46:33 <gyee> bknudson, no, we'll need to change the policy to allow self-management of credentials
18:46:42 <gyee> right now only admin can access the credential APIs
18:46:45 <jamielennox> gyee: does barbican have it's own credential store
18:46:57 <jamielennox> like raw for ssh keys and whatever
18:46:59 <gyee> jamielennox, barbican is a credential store
18:47:02 <morganfainberg> gyee, magic migration from service -> other service is always painful and if anything should be done via a side-band script not the API
18:47:02 <bknudson> gyee: what if the user doesn't provide a token? (e.g., client cert)
18:47:14 <morganfainberg> gyee, no "magic" migration needing user tokens.
18:47:24 <gyee> bknudson, no token, no love
18:47:30 <jamielennox> gyee: right - i mean that isn't specific to a certain credential type - you can put anything in our credentials
18:48:01 <stevemar> jamielennox, which is probably not a good thing for our credentials API
18:48:01 <gyee> morganfainberg, sure, we can call that out in the spec
18:48:02 <morganfainberg> gyee, you can make a barbican-manage or keystone-to-barbican that can leverage the SQL models etc. but not worth trying to use the REST API for migration.
18:48:29 <morganfainberg> gyee, bad idea - because once you flip the bit to use the new driver how do you access the old data? or vice-versa
18:48:33 <jamielennox> i'm wondering if we can't just turn our credential store off (by config) if barbican is in the deployment
18:48:33 <gyee> jamielennox, our credential API is very generic right now
18:48:58 <morganfainberg> bknudson we don't need auth_token in front of keystone, technically auth_context does most of the same stuff w/o the "go talk to keystone" bits.
18:49:08 <morganfainberg> bknudson, and we do store the token in the token_model
18:49:09 <dolphm> morganfainberg: ++
18:49:28 <bknudson> nice thing about auth_token is now it gives you an auth plugin.
18:49:37 <bknudson> maybe we could get that in keystone's auth_context.
18:49:45 <gyee> morganfainberg, we can make keystone credential API "read-only"
18:49:48 <gyee> or configurable
18:50:06 <gyee> and users manages their credential using barbican rest API
18:50:08 <morganfainberg> bknudson, sure. we should retrofit some of that into auth_context (actually we need to break up auth_token into consumable bits that keystone can put into auth_context)
18:50:15 <jamielennox> bknudson: we do need to come up with ways of sharing between auth_token and auth_context
18:50:22 <morganfainberg> gyee, hm, sounds like we don't need a credential api then!
18:50:37 <morganfainberg> gyee, no magic migration using rest. i'll -2 that really fast.
18:50:38 <jamielennox> morganfainberg: that was where i was going
18:50:40 <stevemar> morganfainberg, it's pretty useless right now
18:50:45 <morganfainberg> stevemar, agreed
18:50:59 <gyee> so no barbican integration then?
18:51:05 <bknudson> deprecate it and say use barbican?
18:51:13 <stevemar> bknudson, ++
18:51:16 <jamielennox> bknudson: ++
18:51:19 <Haneef> morganfainberg: but heat uses it in current form
18:51:23 <morganfainberg> bknudson, uh can we do that?
18:51:39 <stevemar> i think thats the path we want in the end, not sure how feasible that is, especially since it's an incubator project still
18:51:40 <morganfainberg> Haneef, we can fix that
18:51:46 <jamielennox> Haneef: these things never go away instantaneously (or ever)
18:51:46 <morganfainberg> stevemar, big tent
18:52:00 <morganfainberg> ok this is a TC issue... i think
18:52:07 <morganfainberg> we're back to deprecate API
18:52:11 <morganfainberg> for *service*
18:52:23 <morganfainberg> erm superseded by *other service*
18:52:31 <stevemar> i think so
18:52:46 <morganfainberg> this is harder to do right and there are no real guidelines that are clear
18:52:59 <morganfainberg> ideally we should get heat and other things to use barbican
18:53:00 <bknudson> nova is trying to deprecate their apis.
18:53:04 <gyee> its easy to *say* deprecating stuff, not so easy to do ;)
18:53:07 <bknudson> e.g., for glance and neutron
18:53:14 <morganfainberg> then credential api becomes like LDAP assignment
18:53:17 <bknudson> so I don't think it's a new thing.
18:53:22 <morganfainberg> limited use and we can deprecate
18:53:31 <morganfainberg> but for now we can't deprecate.
18:53:37 <lbragstad> 7 minutes left
18:53:48 <gyee> fact is deployer wants secure storage of credentials
18:53:58 <morganfainberg> gyee, fact deployer should use barbican
18:54:00 <stevemar> morganfainberg, you have an item to take this up with the tc?
18:54:05 <mordred> deployer should just put them in a file owned by root
18:54:18 * mordred shuts up
18:54:18 <gyee> heh
18:54:20 <jamielennox> gyee: i'd vote no for the barbican backend, and put work into fixing nova heat etc to move away from the keystone credential store
18:54:39 <morganfainberg> gyee we should fix the stuff that *used* credential to use barbican as appropriate.
18:54:49 <morganfainberg> gyee, and get heat moved over to barbican
18:54:50 <Haneef> jamielennox: +1
18:54:52 <stevemar> morganfainberg, there we go
18:54:53 <bknudson> we might be asked to provide a barbican backend to make migration easier.
18:55:02 <stevemar> ha
18:55:13 <gyee> k, k
18:55:17 <stevemar> 5 minutes left, i'm going to next topic
18:55:30 <stevemar> #topic Request for PowerKVM platform CI to comment on Keystone patches
18:55:34 <stevemar> krtaylor, ping
18:55:39 <krtaylor> o/
18:55:42 <morganfainberg> krtaylor, sorry for the short time
18:55:43 <krtaylor> Hi all
18:55:45 <krtaylor> np
18:55:56 <krtaylor> background, we (PowerKVM) turned on comments for the Keystone testing that we are doing on our platform
18:56:08 <krtaylor> we started commenting on keystone patches without asking first, that was probably rude of us, but it is now turned off
18:56:08 <morganfainberg> so the real quick question is: what are you testing where keystone voting will benefit from PowerKVM scoring?
18:56:14 <lbragstad> is there anything you expect keystone to break on powerkvm? We don't have anything virt specific
18:56:19 <morganfainberg> afaik powerkvm is only nova-related?
18:56:25 <morganfainberg> lbragstad, exactly
18:56:46 <krtaylor> it would be commenting only, I don't expect that we would ever vote
18:57:01 <morganfainberg> again, what are we solving with the comments?
18:57:07 <krtaylor> powerkvm is a platform, not a driver or hypervisor
18:57:15 <lbragstad> would we be able to look at the code after a failure?
18:57:20 <krtaylor> we test on a different architecture
18:57:22 <dolphm> i appreciate the desire to test all integrated projects on a specific platform, but i would never appreciate a -1 on a keystone patch from powerkvm as i imagine that would only ever be a transient error
18:57:35 <morganfainberg> dolphm, ++
18:57:36 <krtaylor> with a different toolchain, different dependencies
18:57:38 <gyee> dolphm ++
18:57:49 <krtaylor> agreed
18:57:58 <krtaylor> we would not vote
18:58:07 <morganfainberg> krtaylor, ok so i think i don't understand powerkvm well enough and what you're building
18:58:26 <stevemar> if db2 is included as part of the tools, instead of mysql, i could see the benefit; not sure if thats the case
18:58:27 <morganfainberg> krtaylor, my only real concern is noise to signal
18:58:40 <dolphm> so, IF powerkvm votes, a +1 would be maybe useful as a smoketest? krtaylor what would you comment on, otherwise?
18:58:43 <krtaylor> as always, it can be turned on/off with the toggle button at the bottom of the comments
18:58:53 <morganfainberg> is there *ever* a case where a failure from powerkvm will result in useful data to us? or a success?
18:59:02 <krtaylor> here is an example of our commenting
18:59:10 <krtaylor> https://review.openstack.org/#/c/152550/
19:00:01 <stevemar> #endmeeting