18:00:37 <lbragstad> #startmeeting keystone
18:00:38 <openstack> Meeting started Tue Feb 28 18:00:37 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:42 <openstack> The meeting name has been set to 'keystone'
18:00:49 <lbragstad> ping agrebennikov, amakarov, annakoppad, antwash, ayoung, bknudson, breton, browne, chrisplo, cmurphy, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nishaYadav, nkinder, notmorgan, portdirect raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, SamYaple, shaleh, spilla, srwilkers,
18:00:49 <lbragstad> StefanPaetowJisc, stevemar, topol, shardy, ricolin
18:00:51 <browne> o/
18:00:56 * notmorgan hides
18:00:56 <knikolla> o/
18:00:56 <lbragstad> agenda #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:57 <ayoung> Heyo!
18:01:00 <lbragstad> o/
18:01:00 <gagehugo> o/
18:01:02 <spilla> o/
18:01:02 <cmurphy> o/
18:01:06 <lamt> o/
18:01:19 <rderose> o/
18:01:44 <dstanek> o/
18:02:08 <lbragstad> hopefully everyone had a productive week
18:02:19 <topol> o/
18:02:38 <lbragstad> ravelar antwash o/
18:02:43 <antwash> o/
18:02:47 <ravelar> lbragstad o/
18:03:03 <lbragstad> alright - let's get started
18:03:19 <lbragstad> #topic PTG Topics
18:03:20 <lbragstad> #link https://etherpad.openstack.org/p/pike-ptg-keystone-ocata-carry-over
18:03:21 <lbragstad> ...
18:03:22 <lbragstad> #topic PTG Topics
18:03:29 <lbragstad> #link https://etherpad.openstack.org/p/pike-ptg-keystone-ocata-carry-over
18:03:42 * lbragstad notes that copy paste fails with meeting bot
18:04:20 <lbragstad> we planned on having a session at the PTG dedicated to addressing carry over topics from ocata
18:04:25 <lbragstad> as well as backlogged specs
18:04:49 <lbragstad> but we came to the conclusion that is something we can do in meeting versus valuable hacking time person
18:05:10 <lbragstad> so i figured we'd try and knock a few of them out today, while the discussions from the PTG are still fresh
18:05:22 <lbragstad> #topic PTG Topics: Project and domain tags
18:05:42 <lbragstad> i wasn't there for this particular topic, but it sounds like someone had an action item to rework a spec?
18:05:49 <samueldmq> o/
18:06:04 <gagehugo> lbragstad https://review.openstack.org/#/c/431785/
18:06:05 <notmorgan> project and domian tags?
18:06:24 <notmorgan> oh that
18:06:28 <lbragstad> notmorgan yeah - it was the first thing on the schedule wednesday morning
18:06:31 * notmorgan shrugs.
18:06:49 * notmorgan is generally not a fan but doesn't care to argue about it too much
18:06:54 <lbragstad> gagehugo aha - cool
18:07:15 <lbragstad> gagehugo i'll update the PTG etherpad, too
18:07:25 <ayoung> call em labels, and be consistent with Kubernetes
18:07:25 <lbragstad> #topic PTG Topics: Microversioning
18:07:43 <gagehugo> lbragstad ok
18:07:43 <lbragstad> based on the feedback in the etherpad, it doesn't sound like we're going to pursue this?
18:07:55 <lamt> I think the discussion is ongoing with the API-WG
18:07:58 * ayoung prefers macroversioning
18:08:16 <lbragstad> lamt was there a consensus reached at the PTG in the API-WG session?
18:08:26 <dstanek> lbragstad: yes, we decided to pass since we don't have a reason for it and it makes client/horizon's life much harder
18:08:33 <lamt> but it is needed to resolve some bugs at some point: https://bugs.launchpad.net/keystone/+bug/1660603
18:08:33 <openstack> Launchpad bug 1660603 in OpenStack Identity (keystone) "Difference in Implied Roles check API return code" [High,Confirmed]
18:08:37 <samueldmq> dstanek: ++
18:08:37 * ayoung proposing Keystone API Version 6.  Cuz termie already claimed 4 and 5
18:09:01 <rderose> dstanek: yeah, that was my understanding as well
18:09:07 <lbragstad> would anyone be opposed to me removing it from the backlog until the API-WG comes to consensus on the approach?
18:09:13 <lamt> no there are some issues they raised regarding interop
18:09:16 <dstanek> i mention using the microvesion approach next time we update major versions as a way to make trasition easier
18:09:34 <notmorgan> ayoung: wfm.
18:10:00 <samueldmq> lbragstad: that sounds a reasonable plan for me.
18:10:03 <notmorgan> ayoung: though i'm -2 on an even number, #justbecause
18:10:12 <lbragstad> I feel like our spec would probably need to be rewritten in order to encompass the direction of the API-WG
18:10:22 <dstanek> lbragstad: we talked about having a non-backlog dumping ground for this sort of stuff
18:10:35 <notmorgan> lbragstad: i dislike microversions intensely. but i don't really care about shuffing it off the backlog or not.
18:10:36 <dstanek> i don't remember what the possible names were
18:10:42 <notmorgan> so if it makes it easier for you, lets do it
18:11:21 <lbragstad> I personally wouldn't mind periodically updating the backlog so that new folks on the project don't go chasing something we've already come to a decison on
18:11:25 <lbragstad> decision*
18:11:49 <ayoung> notmorgan, 7 it is
18:12:06 <ayoung> I thought we were going to go fibonacci
18:12:22 <notmorgan> ayoung: i like prime numbers
18:12:22 <dstanek> lbragstad: yeah, backlog should be the things we intend on doing rather than just a parking spot
18:12:39 <lbragstad> #action lbragstad to remove microversion spec from backlog linking to this discussion
18:12:52 <samueldmq> dstanek: lbragstad: I agree with you.
18:13:01 <lbragstad> cool
18:13:40 <lbragstad> #topic PTG Topics: Improving OIDC support
18:13:51 <lbragstad> is anyone interested in picking up the spec proposal to get it merged to backlog if it's still useful?
18:13:55 <antwash> ]
18:14:22 <lbragstad> #link https://review.openstack.org/#/c/373983 ?
18:14:47 <lbragstad> we can keep it in review until we have someone to do it, too
18:15:10 <rderose> lbragstad: I haven't reviewed, but could take a look
18:15:12 <lbragstad> I was thinking if it sounded useful and if it's something we should do, we should at least merge it to backlog until we have bandwidth to adderss it
18:15:19 <lbragstad> rderose ++ that'd be helpful
18:15:25 <knikolla> i'll give it a read
18:15:57 <breton> the only thing that bugs me in the spec is that keystone makes request to external resource via http
18:16:31 <samueldmq> lbragstad: I think aloga proposed that ^
18:16:52 <lbragstad> samueldmq aha - good call
18:17:03 <samueldmq> could be useful to check with him if he wants/has time to to revive it :-)
18:17:08 <samueldmq> :)
18:17:19 <lbragstad> samueldmq ++
18:18:07 <lbragstad> #topic PTG Topics: Pluggable fernet backend
18:18:13 <lbragstad> breton?
18:18:25 <lbragstad> do we have an outlook on this for Pike?
18:18:38 <lbragstad> if not, that's just fine, i'm just trying to gauge the current status
18:18:42 <breton> i won't work on it this cycle and i don't think it is still needed
18:18:49 <lbragstad> ok
18:19:00 <lbragstad> anyone else feel differently about this?
18:19:02 <breton> for kubernetes it was solved via secrets
18:19:30 <lbragstad> dstanek ?
18:20:43 <ayoung> I do!
18:20:56 <ayoung> lbragstad, there is a tool called Custodia
18:21:11 <ayoung> its designed to do Secrets right, and the goal is to plug it in to oslo-config
18:21:19 <breton> oh, well, yes, from the perspective this is still needed
18:21:25 <ayoung> so on a given field, you say "and this field comes from custodia
18:21:27 <ayoung> "
18:21:54 <ayoung> then we get secure secrets without having to rewrite ever single service in OpenStack
18:22:00 <dstanek> lbragstad: i wasn't pushing this one
18:22:04 <lbragstad> ayoung breton so are we fine opting for that instead of a pluggable fernet backend?
18:22:21 <ayoung> and...once we get it working for Custodia, we can use the same tool for fernet, and might I add, credentials
18:22:35 <lbragstad> ok - that makes sense
18:22:45 <ayoung> lbragstad, yes
18:22:55 <dstanek> custodia would just be a backend right?
18:23:01 <lbragstad> regardless - that should be a new spec that proposes using that implementation over our own pluggable implementation
18:23:39 <dstanek> lbragstad: hmm....so that wouldn't just be a backend?
18:23:48 <ayoung> dstanek, sort of
18:23:50 <breton> the spec should describe why we want it
18:23:58 <ayoung> dstanek, it would be an optional plugin to oslo-config
18:24:28 <dstanek> how does that relate to storing fernet keys off of the filesystem?
18:24:30 <ayoung> load it the way we do the Kerberos modules
18:24:40 <ayoung> dstanek, that is what Custodia is for
18:25:03 <ayoung> secret delivery. Can be stored in the kernel keyring, delivered vuia DBSU, or a few other options
18:25:11 <ayoung> https://github.com/latchset/custodia
18:25:18 <lbragstad> so maybe we should remove the implementation details of the fernet key store spec and make it super general,
18:25:20 <dstanek> i'm not following  why it's an oslo.config thing
18:25:45 <ayoung> dstanek, and, if that does not work for everyone, at least we have a proof-of-concept in place for doing secrets securely in oslo, maybe using different plugins there
18:26:07 <ayoung> dstanek, because you are thinking about how Fernet is done today
18:26:09 <ayoung> which is dumb
18:26:18 <ayoung> it is dumb because it has to be
18:26:31 <dstanek> i was thinking something super simple like a backend that has a single method that returns a list of keys.
18:26:42 <ayoung> because we did not give proper key support in oslo-config so lbragstad and the other Fernet devs had to solve it themselves
18:26:50 <dstanek> i don't want to do something that would make us depend on another service
18:26:52 <ayoung> dstanek, oh, we could do that,.
18:27:00 <ayoung> but then we still have database passwords in config files
18:27:03 <ayoung> and rabbit passwords
18:27:06 <ayoung> and all that crap
18:27:28 <ayoung> solve it once;  and then Fernet makes use of that solution.  As does credentials
18:27:35 <dstanek> ayoung: i'm not saying that we shouldn't try to get rid of it only that making keystone depend on another service is a big deal
18:27:55 <ayoung> dstanek, it isn't
18:28:05 <ayoung> dstanek, it is going to depend on oslo-config.  Only that
18:28:21 <dstanek> keystone -> oslo.config -> credentia?
18:28:21 <ayoung> Custodia will be there only for people that want it off system
18:28:22 <lbragstad> so - where is oslo.config going to store things?
18:28:48 <dstanek> or are you proposing make introduce the idea of backends to olso.config
18:29:16 <ayoung> dstanek, I am proposing, on a key-by-key bases, to have backends for oslo.config
18:29:18 <lbragstad> that's how i understood it
18:29:49 <ayoung> I know who is going to implement this, but I am not yet at liberty to say
18:30:04 <dolphm> so, fernet keys would be a multistringopt?
18:30:16 <ayoung> dolphm, I think so, yes
18:30:16 <lbragstad> does it rhyme with Shemed Bat?
18:30:28 <ayoung> lbragstad, nope
18:30:29 <dolphm> i've never met a deployer that could deal with multistring opts
18:30:37 <ayoung> dolphm, heh
18:30:55 <ayoung> dolphm, it could still be 3 string options: fernet1 fernet2 fernet3
18:30:58 <ayoung> I don't really care
18:31:02 <dstanek> if we only do this in oslo.config then key rotation will suck for file based keys
18:31:39 <ayoung> dstanek, key rotation already sucks unless you are doing it solely on a single instance
18:32:09 <lbragstad> it was designed to work for a cluster from a single instance
18:32:30 <dolphm> to be orchestrated, though
18:33:27 <ayoung> yeah but that is nothing like a complete solution.  Copying around cleartext keys is a poor security mechanism
18:33:56 <dolphm> that's not really different than copying around secrets in config files in plain text
18:34:11 <dstanek> i'm just saying that we need to understand the whole picture before we change direction too much
18:34:18 <ayoung> so...we should be able to continue to support the fernet-in-its-own file thing via oslo anyway, as we already have some code like that for domain specific backends
18:34:31 <lbragstad> do we agree that we *don't* want to pursue a pluggable fernet backend?
18:34:35 <ayoung> so...let me redefine the problem
18:34:52 <dolphm> i've been trying to read back, and i'm lost as to what the problem being solved here actually is?
18:34:57 <dstanek> i'd be interesting in seeing an x-project spec that deals with oslo.config, rotation, etc.
18:35:05 <ayoung> how do we manage secrets; fernet, credentials, sql passwrods, and rabbit passwords
18:35:06 <lbragstad> dolphm i'm revisiting all the carry over topics from ocata
18:35:13 <dstanek> dolphm: there is a want to make a fernet backend for keystorage
18:35:27 <lbragstad> i really just need to know if we want to pursue the fernet key store backend spec
18:35:31 <dstanek> so that someone can store in DB, something else, etc and not on the filesystem
18:35:33 <lbragstad> or if I can remove it from the backlog
18:35:50 <dstanek> lbragstad: someone actively wanted that...are they still interested?
18:36:05 <dolphm> dstanek: oh, sure. how does this relate to oslo.config? barbican does not return config files
18:36:17 <lbragstad> dstanek i thought that was breton but I could be wrong
18:36:41 <dstanek> dolphm: ayoung wants to update oslo.config to optionally use a third-party service to store passwords so that they are not in the config file
18:36:47 <dstanek> it's on tangentially related
18:36:49 <ayoung> right
18:37:03 <ayoung> and I want fernet and credentials keys to use that same mechanism
18:37:19 <lbragstad> if that's the case - we should document the need for a pluggable backend of somekind and fix the spec
18:37:40 <dstanek> if we do break this up into backends then one for that wouldn't be terribly hard
18:37:49 <ayoung> lbragstad, I am waiting for the person that is going to work on this to take it over.  I'll let that person write the spec
18:38:18 <dstanek> i don't think that's necesarily a pike thing....but is fernet backends?
18:38:21 <lbragstad> ayoung can you suggest to said person to take over the fernet backend spec?
18:38:40 <breton> dstanek: lbragstad: it was me for a specific reason -- containers
18:38:45 <lbragstad> or update it if/when we come to consensus on the approarch?
18:39:02 <ayoung> lbragstad, if and only if it is done by Custodia (first) as that is what the engineer is hired to work on.  Otherwise, that person will just work on oslo.config support for secrets.
18:39:07 <ayoung> not my call
18:39:10 <breton> dstanek: lbragstad: it was solved for containers and i don't work at a place where containers are, so i don't want that that much any more
18:39:15 <breton> but ayoung has a point
18:39:52 <dstanek> breton: ah right
18:40:43 <ayoung> dstanek, lbragstad please read up on Custodia, and I will have the person working on it engage as soon as orientation is complete
18:40:45 <dstanek> lbragstad: if nobody i actively asking for it i say punt
18:40:54 <dstanek> we can always revisit later if/when someone cares
18:40:57 <lbragstad> alright
18:41:10 <dstanek> ayoung: it sounds like a simple version of barbican
18:41:19 <lbragstad> works for me
18:41:29 <lbragstad> #action lbragstad to remove the fernet pluggable backend spec linking back to this discussion
18:41:30 <ayoung> dstanek, that ideas are very comparable
18:41:45 <lbragstad> #topic Backlogged specs: Using alembic for migrations
18:41:53 <dstanek> woot - another one bites the dust
18:42:04 <lbragstad> do we have consensus that this is not needed?
18:42:18 <lbragstad> that was prior to all the work for rolling upgrades
18:42:33 <lbragstad> which makes our structure around using sqla a little more involved
18:43:03 <rderose> lbragstad: ++ not needed
18:43:05 <lbragstad> so - i would have imagined that if we wanted to accomplish this, we would have done so before we implemented rolling upgrade support
18:43:42 <dstanek> i thought migrate was on it's last let and we will need to move eventually
18:43:49 <bknudson_> we might not have a choice if sqlalchemy-migrate is dropped
18:43:55 <dstanek> bknudson_: ++
18:44:32 <lbragstad> sqla-migrate might be dropped?
18:44:40 <dstanek> this wasn't for rolling upgrades it was because alembic is the new, supported hottness
18:44:50 <lbragstad> right
18:44:55 <bknudson_> I don't think it's being maintained anymore.
18:45:01 <dstanek> lbragstad: iiuc it's dead
18:45:18 <lbragstad> sweet
18:45:31 <samueldmq> so that means we still want to replace sqla-migrate with that
18:45:36 <lbragstad> so - does it make sense to update the alembic spec specifying the need to keep it around for that case?
18:45:49 <samueldmq> lbragstad: should be nice to have this cycle if that does not take too much effort
18:46:13 <dstanek> lbragstad: probably
18:46:18 <samueldmq> lbragstad: it does for me
18:46:20 <lbragstad> well - that's the real question... so far i don't think i've heard much negative feedback on our current approach
18:46:39 <lbragstad> so if it's any more than trivial i would probably not spend cycles on it
18:46:48 <dstanek> we forked it to make updates since it's dead https://github.com/openstack/sqlalchemy-migrate
18:46:50 <lbragstad> s/it's/moving to alembic/
18:47:11 <dstanek> lbragstad: agreed.... we are ok in the short term
18:47:27 <lbragstad> #action update the alembic spec to clarify the need if sqla-migrate goes away
18:47:54 <lbragstad> i think we have time for one more
18:47:56 <lbragstad> #topic Backlogged specs: Centralized Policies Distribution Mechanism
18:47:57 <bknudson_> I wonder how many projects are using sqlalchemy-migrate?
18:48:13 <dolphm> glance *just* switched to alembic
18:48:15 <lbragstad> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/centralized-policies-delivering-mechanism.html
18:48:20 <lbragstad> does this still make sense?
18:48:41 <samueldmq> lbragstad: I think all those in policy should be invalid/on hold for now
18:49:03 <samueldmq> given the agreed cross-project directions/priorities
18:49:18 <dstanek> samueldmq: ++ i don't know how to reconcile that with our current nova-driven direction
18:49:18 <lbragstad> yeah - i'm inclined to say the same
18:49:26 <samueldmq> we're not focusing on centralizing it in any way inthe cross-project, at least now
18:49:35 <samueldmq> exactly
18:49:44 <knikolla> ayoung: that includes role check in middleware i believe
18:50:30 <ayoung> depends on whether my talk gets approved
18:50:42 <samueldmq> would be nice to keep'em in a separate place (things-we-might-consider-revisiting-in-the-future), but not backlog
18:51:04 * samueldmq refers to his specs on centralizing policy on keystone and fetching'em on middleware for enforcement
18:52:12 <lbragstad> if after all the policy-in-code and documentation work happens we have a clear path forward with an approach that centralizes policy, we can repropose it
18:52:53 <samueldmq> lbragstad: ++
18:53:18 <lbragstad> #action remove  Centralized Policies Distribution Mechanism spec from backlog
18:53:30 <lbragstad> alright - we can be done there... leaves some time for open discussion
18:53:38 <lbragstad> #topic open discussion
18:53:57 <lbragstad> bueller?
18:54:01 <samueldmq> lbragstad: there was also Decouple auth from API version and Materialized Path for HMT
18:54:08 <samueldmq> want to discuss that next time ?
18:54:19 <lbragstad> samueldmq yeah - i figured we can discuss those next week
18:54:24 <samueldmq> neat
18:55:18 <lbragstad> does anyone have anything they want to talk about from the ptg?
18:55:48 <lbragstad> I should have a recap posted sometime today that summarizes things from a keystone-perspective
18:55:48 <dstanek> i enjoyed the PTG - from my perspective it was just like the design summit, but maybe more focused
18:56:17 <lbragstad> dstanek ++
18:56:39 <lbragstad> I'm curious to see how the feedback gets rolled into the next one
18:56:39 <samueldmq> same here, although the first 2 days (cross-proj) might need some restructure/organization on topics
18:56:54 <samueldmq> participation was quite low on the first 2 days when compared to the rest
18:57:25 <lbragstad> yeah - i'm going to try and push to be there the first two days next time, if we follow the same horizontal/vertical format
18:57:37 <samueldmq> nice
18:57:54 <samueldmq> other than that, it was great to see you all there :)
18:58:04 <lbragstad> ++ yeah - it was a good week
18:58:10 <rderose> samueldmq: ++
18:58:27 <lbragstad> unless anyone has anything else, i'll let everyone get a couple minutes back
18:58:36 <dstanek> yeah, that was a little difficult, but i think was mostly company driven
18:58:45 <lbragstad> dstanek true
18:59:07 <lbragstad> dstanek that could be a thing that is cleared up with communication, too
18:59:38 <lbragstad> well - thanks for coming everyone!
18:59:42 <lbragstad> #endmeeting