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