18:00:02 <lbragstad> #startmeeting keystone
18:00:03 <openstack> Meeting started Tue Nov 21 18:00:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:05 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar
18:00:06 <openstack> The meeting name has been set to 'keystone'
18:00:12 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:14 <lbragstad> agenda ^
18:00:18 <lbragstad> o/
18:00:22 <hrybacki> o/
18:00:31 <lamt> o/
18:00:55 <lbragstad> i dropped the ball on the meeting last week - sorry about that
18:01:39 <lbragstad> we don't have a whole lot on the schedule today - so we'll give it a few minutes for folks to trickle in
18:01:43 <lamt> DST was rough esp after travel from the summit
18:01:49 <lbragstad> ++
18:02:45 <lbragstad> yeah - between travel, jet lag, dst, and parsing missed work, i'm not sure when i really recovered
18:03:03 <hrybacki> have you fully recovered? ;)
18:03:13 <lbragstad> lol that's the real question
18:03:25 <hrybacki> RH Tower has been awfully quiet this and last week as well
18:03:37 <lbragstad> yeah - i've noticed that, too
18:03:50 <lbragstad> which wasn't terrible because it was a nice opportunity to catch up on this and provide recaps
18:04:14 <lbragstad> #topic specification reviews
18:04:21 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-November/124727.html
18:04:40 <lbragstad> i took a look at our roadmap and what we have let to merge for specs that we've committed to
18:04:57 <lbragstad> there are a couple outstanding ones that we need to get updated and reviewed within the next couple weeks
18:05:05 <lbragstad> any extra eyes on those would be awesome
18:05:38 <lbragstad> i said this in the email, too.. but if anyone is looking to tag-team something, feel free to speak up
18:05:56 <lbragstad> #topic summit recaps
18:06:07 <lbragstad> cmurphy: just published #link http://www.gazlene.net/sydney-summit.html
18:06:26 <hrybacki> have not read her recap yet
18:06:26 <lbragstad> and i have my take #link https://www.lbragstad.com/blog/openstack-summit-sydney-recap
18:06:48 <lbragstad> has anyone else published a keystone recap of any kind?
18:07:21 <lbragstad> if someone has, let me know and i'll advertise it accordingly
18:07:38 <knikolla> o/ (sorry for being late)
18:07:49 <lbragstad> does anyone have comments or questions on the recaps?
18:08:25 <hrybacki> not atm
18:08:42 <lbragstad> cool - well if you notice anything inconsistent in mine, ping me
18:08:48 <lbragstad> #topic office hours schedule
18:08:57 <lbragstad> when i set this up - i don't think i actually set it for dst
18:09:30 <lbragstad> i'm curious if folks want to move office hours to be right after the meeting or leave it where it is (meaning we have an hour between the keystone meeting and the start of office hours)
18:09:48 <lbragstad> thoughts?
18:10:20 <KwozyMan> lbragstad: For us (Central Europe), it would be better to have it one hour earlier.
18:10:23 <hrybacki> Do we have normal meetings follow US DST in OpenStack?
18:10:57 <lbragstad> KwozyMan: as in moving office hours to be right after the keystone meeting, regardless of dst?
18:11:18 <kmalloc> lbragstad: i thought that was already the case
18:11:21 <kmalloc> heh
18:11:23 <lbragstad> to my knowledge, openstack meetings are held in UTC, so they are subject to DST changes
18:11:30 <kmalloc> why are office ours not in UTC then?
18:11:36 <kmalloc> and yes, meetings are in UTC
18:11:45 <lbragstad> kmalloc: it was supposed to be (but i don't think i scheduled it that way)
18:11:45 <KwozyMan> lbragstad: just telling you how it would be best here
18:12:06 <lbragstad> KwozyMan: ack - that makes sense, i suppose it keeps things late for you
18:12:10 <lbragstad> if you're in central europe
18:12:19 <josecastroleon> me too
18:12:40 <lbragstad> ok - cool
18:12:55 <lbragstad> is anyone actually in favor of an hour gap between the team meeting and office hours?
18:14:06 <lbragstad> #action keep office hours immediately after the keystone meeting - subject to DST changes
18:14:20 <lbragstad> #topic open discussion
18:14:29 <lbragstad> alrighty - floor is open
18:16:01 <hrybacki> lbragstad: if there existed a set of policy files for various services that created what amounts to a read-only-role would upstream have interest in pulling those in?
18:16:30 <hrybacki> policy-in-code stuff aside
18:16:33 <lbragstad> sure
18:16:40 <lbragstad> i think that would certainly be useful
18:16:52 <lbragstad> since there is a need for it and that's been proven by several operators
18:16:59 <lbragstad> implementation-wise
18:17:14 <lbragstad> i'm not sure we'd keep the policy files in tree (since we're moving away from that model)
18:17:22 * hrybacki nods
18:17:32 <lbragstad> but documenting them somehow somewhere would be good
18:17:56 <lbragstad> along with a document that explains the rationale (which would need to be updated with the system-scoping work)
18:18:19 <hrybacki> ack. okay cool, I'll brainstorm more with you offline?
18:18:21 <lbragstad> yeah - i think that would be useful as a stop-gap until we fix things
18:18:30 <lbragstad> ++
18:18:31 * hrybacki nods
18:19:55 <josecastroleon> lbragstad: we have been reviewing our stuff once back from the summit
18:20:14 <josecastroleon> we have quite some things we can submit
18:20:21 <josecastroleon> on the LDAP part
18:20:26 <lbragstad> nice!
18:21:16 <lbragstad> has any of it been recorded publicly?
18:21:24 <lbragstad> (bug reports, specs, blueprints, etc...)?
18:21:47 <josecastroleon> not yet but they will be soon, right? KwozyMan
18:22:00 <KwozyMan> aye
18:22:06 <lbragstad> KwozyMan: you must be at CERN?
18:22:17 <KwozyMan> lbragstad: I am
18:22:25 <lbragstad> KwozyMan: awesome - happy to have you here
18:22:44 <KwozyMan> thank you, hope to be able to help
18:23:00 <lbragstad> don't hesitate to reach out if you have any questions
18:23:17 <KwozyMan> alright, I'll start lurking on #keystone
18:23:46 <lbragstad> good deal - you should be able to find all of us in #openstack-keystone
18:24:29 <lbragstad> does anyone have anything else?
18:24:36 <josecastroleon> quick one, have you discussed already about the project id configured by the operator?
18:24:51 <josecastroleon> the one that came on the summit from orange
18:24:56 <lbragstad> josecastroleon: i just came across that bug report this morning
18:25:02 <josecastroleon> sorry
18:25:05 <lbragstad> oh - wait, nevermind
18:25:08 <lbragstad> yeah
18:25:14 <lbragstad> i was thinking of a separate bug
18:25:22 <lbragstad> i spent about a day digging last week
18:25:37 <lbragstad> i went through all keystone source back to diablo to try and figure out the paper trail there
18:26:11 <lbragstad> but since kmalloc is here, he's pretty much the project historian at this point ;)
18:27:27 <lbragstad> josecastroleon: i attempted to document the new requirements in the recap i wrote
18:27:29 <lbragstad> #link https://www.lbragstad.com/blog/openstack-summit-sydney-recap
18:27:34 <lbragstad> specifically in the Other Feedback section
18:27:51 <lbragstad> (kmalloc can probably correct me here)
18:28:18 <lbragstad> i thought we came out of that session with two new requirements that I don't think we were aware of the first time we discussed this ability of the API
18:28:36 <lbragstad> 1.) Authorization data must not come from the source of authentication
18:28:42 <lbragstad> 2.) Data replication at the database layer might not be possible due to data security issues between countries
18:31:19 <lbragstad> when #link https://review.openstack.org/#/c/241346/ and #link https://review.openstack.org/#/c/323499/ were proposed, we thought it was a way to get around using federation
18:31:47 <josecastroleon> from the comments on the reviews I think so too
18:31:52 <lbragstad> or a way to mitigate database replication because of poor performance
18:32:16 <lbragstad> in talking to operators at the summit - i'm not sure the poor performance was a concern, that actually didn't sound like the problem
18:32:50 <lbragstad> the problem, as I interpreted it, was that there are laws in place that prevent you from being able to replicate traffic across borders
18:33:44 <lbragstad> josecastroleon: is that how you understood it, too?
18:34:14 <josecastroleon> on a telco, that's probably their main constraint
18:34:57 <josecastroleon> on our side, it was more due to the lack of properties on the projects at the time we deploy our cloud
18:35:46 <lbragstad> that feature was only for specifying a specific project ID at project creation time, right?
18:35:57 <josecastroleon> yes
18:37:40 <lbragstad> so you'd use it to make sure the projects in other data centers have the same IDs?
18:37:49 <lbragstad> as the legacy projects you already have in your deployment?
18:38:17 <josecastroleon> on our case, it's a bit different
18:38:52 <josecastroleon> there is an lifecycle management tool that creates the projects
18:39:20 <josecastroleon> so when a user leaves the resources that he is managing are not orphaned/lost
18:40:06 <josecastroleon> this entity identifies the resources by uuids
18:40:19 <josecastroleon> and as the projects at that moment did not have properties
18:40:39 <josecastroleon> we choose the id for storing it
18:41:28 <lbragstad> ah
18:41:33 <josecastroleon> on our side we can try to move to a property, but the existing projects will be tough to move
18:41:44 <josecastroleon> project ids
18:41:49 <lbragstad> because you have to change the project id
18:42:03 <josecastroleon> at some point yes
18:43:10 <lbragstad> ok - so maybe what we can do it repropose one of those specifications with the requirements and use cases updated
18:43:17 <lbragstad> i think that would help push the discussion forward
18:43:21 <KwozyMan> lbragstad: any particular point against implementing this?
18:44:43 <lbragstad> for that specific case, i'm not sure... the answer that was documented in the specification eluded to improving federation of building a db replication workaround into keystone's api
18:45:02 <lbragstad> ^ that was the main concern during the original proposal
18:45:34 <lbragstad> because people wanted to have separate keystone's in each region but each region is part of the same deployment
18:46:00 <lbragstad> which was about the extent of the requirement as I remember
18:46:12 <lbragstad> and to several people, that just sounded like federation
18:46:19 <josecastroleon> our use case is a bit simpler
18:46:30 <lbragstad> yeah
18:46:31 <josecastroleon> single data center
18:46:43 <josecastroleon> single federation :D
18:47:18 <KwozyMan> Ok, then I'll have to read up on it. It's not clear why exactly specifying id at creation time is wrong.
18:47:30 <lbragstad> i think it would be useful to repropose the spec and document those use cases and requirements
18:47:48 <josecastroleon> fair enough
18:47:58 <KwozyMan> sounds good
18:48:10 <lbragstad> KwozyMan: i don't think anyone said it was wrong as much as we wanted to improve federation usability instead
18:48:33 <lbragstad> but i don't think all of these requirements were involved the first time we discussed this
18:48:52 <KwozyMan> lbragstad: sorry, just trying to understand. there will be a lot of questions from me, I'm afraid :(
18:49:05 <lbragstad> no worries!
18:49:18 <lbragstad> but we've talked about this a few times
18:49:49 <lbragstad> so i think it would be a good idea to document things in a specification with the new requirements
18:50:00 <lbragstad> then we can iterate on it in review
18:50:01 <KwozyMan> yes, that's a good idea
18:50:27 <josecastroleon> great
18:50:28 <lbragstad> (which is documenting)
18:51:23 <lbragstad> josecastroleon: KwozyMan if either of you are interested in that - i think we could just re-use one of the existing specs
18:51:27 <lbragstad> (keeping the context)
18:51:48 <KwozyMan> lbragstad: send it over
18:52:06 <lbragstad> #link https://review.openstack.org/#/c/323499/
18:52:16 <lbragstad> #link https://review.openstack.org/#/c/241346/
18:52:25 <lbragstad> the second one was the first formal proposal
18:53:07 <KwozyMan> roger that
18:53:37 <lbragstad> KwozyMan: there is a lot of context in there too from other reviewers
18:53:42 <lbragstad> so that might help piece things together
18:54:13 <lbragstad> or paint a more complete picture than what I described here
18:54:58 <lbragstad> anyone have anything else?
18:55:01 <KwozyMan> sounds good
18:55:11 <lbragstad> otherwise we can get a few minutes back before office hours (for those attending)
18:55:18 <kmalloc> oh sorry stepped away for a sec
18:55:23 <kmalloc> someone called me a historian?
18:55:25 * kmalloc reads back
18:55:41 <lbragstad> kmalloc: yeah - we can spill over into -keystone, too
18:56:02 <lbragstad> kmalloc: i think you're opinion on that ^ discussion would be really helpful
18:56:18 <kmalloc> sure. lets catch up in -keystone
18:56:20 <kmalloc> and i can weigh in
18:56:34 <lbragstad> kmalloc: awesome - josecastroleon KwozyMan you free to continue this discussion, too?
18:56:40 <kmalloc> oh that one.
18:56:42 <kmalloc> ugh.
18:56:47 <lbragstad> :)
18:56:51 * kmalloc cowers in the corner
18:57:01 <KwozyMan> lbragstad: for some limited time, I would like to get home at some point
18:57:01 <kmalloc> can i pretend i was never here now ;)
18:57:27 <kmalloc> i can explain the real concerns with that proposal and why it got squashed
18:57:27 <lbragstad> ok - let's continue in -keystone then
18:57:35 <lbragstad> #endmeeting