17:00:08 <knikolla> #startmeeting keystone
17:00:09 <openstack> Meeting started Tue May 19 17:00:08 2020 UTC and is due to finish in 60 minutes.  The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:12 <openstack> The meeting name has been set to 'keystone'
17:00:22 <lbragstad> o/
17:00:35 <cmurphy> o/
17:00:38 <gagehugo> o/
17:00:47 <knikolla> o/
17:00:55 <bnemec> o/
17:01:13 <knikolla> how's everyone doing?
17:01:15 <vishakha> o/
17:01:46 <cmurphy> hanging in there
17:01:52 <lbragstad> same here
17:02:59 <bnemec> Obligatory: https://i2.wp.com/www.newromantimes.com/wp-content/uploads/2016/11/sales-of-hang-in-there-2.jpg
17:03:23 <cmurphy> lol
17:03:32 <knikolla> that is more like hanging out there though
17:04:03 <bnemec> There's a sloth version! https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcQwTynAfWY15vRIBjwfji9b-Qoi04oFzFomjWATBF-txx6H4vUv&usqp=CAU
17:04:25 <knikolla> adorable!
17:04:30 <bnemec> Google image search, the gift that keeps on giving. :-)
17:05:59 <bnemec> lol, for our Suse folks: https://images.fineartamerica.com/images/artworkimages/mediumlarge/2/hang-in-there-magical-chameleon-john-schwegel.jpg
17:06:07 * bnemec is done posting memes
17:06:11 <knikolla> no announcement, but make sure everyone registers for the ptg https://virtualptgjune2020.eventbrite.com/
17:06:51 <knikolla> #topic Review Requests
17:07:34 <vishakha> I have couple of reviews
17:07:53 <vishakha> #link https://review.opendev.org/#/q/topic:update-onboarding+(status:open+OR+status:merged)
17:08:17 <vishakha> Thanks cmurphy  for the reviews. I updated these according to your comments
17:09:09 <vishakha> #link https://review.opendev.org/#/c/728387/
17:09:41 <cmurphy> i haven't had a chance to look at the new revisions but wanted to ask the team, what's the consensus on using the terms "controller" and "manager"?
17:09:47 <vishakha> I blocked patching of access_id of EC2 credentials as discussed. Tempest had no problem with it
17:10:25 <cmurphy> i still always use "controller" and "manager" in my head because i'm old but i can see how that would be confusing to someone looking at the code post-flask and post-providerAPI
17:10:50 <lbragstad> ++
17:10:51 <lbragstad> i agree
17:11:01 <knikolla> i think since there aren't really references to controller in the code anymore, we should update the docs
17:11:46 <cmurphy> what should it be called then? i suggested things like "API resource" in my reviews
17:12:00 <cmurphy> and is the stuff in core.py still a "manager" or is it something else?
17:12:17 <knikolla> good point
17:13:05 <lbragstad> i always mentally mapped "controller" to "this stuff handles request logic" and "managers" contain "keystone-specific business logic"
17:13:15 <cmurphy> lbragstad: yeah exactly
17:13:24 <cmurphy> it's kind of still the same
17:13:29 <lbragstad> yeah
17:13:35 <cmurphy> it's just the python classes and file names don't match
17:13:51 <lbragstad> would that make core.py (the managers) a model?
17:14:09 <lbragstad> meh... probably not
17:14:20 <cmurphy> in an mvc sense i think the sql backend is the model
17:15:15 <lbragstad> right
17:15:31 <lbragstad> so the managers would really be the controllers
17:15:37 <lbragstad> and the controllers would be the view
17:15:41 <cmurphy> heh yeah kind of
17:15:53 * lbragstad isn't helping anything
17:15:56 <cmurphy> :P
17:17:36 <knikolla> let's invent new terminology
17:18:16 <cmurphy> knikolla: suggestions?
17:18:49 <vishakha> API resource seemed reasonable
17:19:21 <knikolla> no, i was just reminded of a team at my work who named the view for a project "picasso" and the manager "einstein" and I got PTSD from reviewing their code.
17:19:34 <cmurphy> hahaha
17:19:38 <cmurphy> personally i think i'd be comfortable continuing to call the providerAPI stuff "managers" and the flask stuff "controllers", or renaming the flask stuff "API ... resources/handlers/controllers/something"
17:20:49 <knikolla> i say we go with API <something> since it's part of their name and file path
17:20:59 <knikolla> /file path/package/
17:22:13 <knikolla> manager and controller have the same implication of being in charge, whereas API doesn't have any connotations.
17:24:03 <cmurphy> the class names for the request handler part are {Thing}Resource so "API Resource" fits
17:24:16 <cmurphy> the routes are defined in {Thing}API but i think we should still call them routes
17:24:43 <knikolla> ++
17:26:51 <vishakha> okay.
17:28:09 <alistarle> Hi, thanks for your review on oslo.limits : https://review.opendev.org/#/q/owner:%22Victor+Coutellier%22+status:open+project:openstack/oslo.limit
17:28:36 <alistarle> I have updated it with your comments
17:28:45 <cmurphy> thanks alistarle
17:29:26 * bnemec still has that window open somewhere
17:29:32 <alistarle> But there is still a openstacksdk patch to be merged for mine to work, I don't used to updating dependency workflow
17:29:51 <cmurphy> bnemec: you can open a new window!
17:30:03 <alistarle> Should I wait for it to be merged, then wait a new version of the sdk, and update the lower-constraints of oslo_limit ?
17:30:09 <bnemec> ETOOMANYWINDOWS
17:30:27 <cmurphy> alistarle: you can add "Depends-on: " with a link to the openstacksdk patch in the commit message
17:30:39 <cmurphy> that will prevent it from being merged before the dependency is merged
17:30:51 <knikolla> bnemec: i keep a firefox addon that doesn't let me open more than 7 tabs
17:31:03 <cmurphy> but it will also probably need a new release of openstacksdk before oslo.limit can use it
17:31:24 <alistarle> And a new release of oslo.limit before using it into glance :/
17:31:31 <cmurphy> right
17:31:57 <alistarle> BTW, I have written the full spec for glance about unified limit, if you want to take a look : https://review.opendev.org/#/c/729187/
17:32:06 <bnemec> knikolla: That would never work for me. :-P
17:32:26 <alistarle> Glance guy's already told me to put that in the PTG agenda, do you think it is usefull to synchronize a session with you ?
17:32:32 <bnemec> Did any of the migration tools ever get written?
17:33:11 <cmurphy> not afaik but i haven't kept up with the nova team on that
17:33:42 <alistarle> I don't think so, neither for glance, but as there is no quota yet, maybe there is no migration :p
17:34:35 <bnemec> Oh, glance doesn't have any existing quotas? That would make it easier. :-)
17:34:57 <alistarle> Yes, only hard limit in config file, that's why I think it will be easier than nova
17:35:05 <cmurphy> oh good
17:36:03 <bnemec> Maybe you can just ping us during the Glance discussion?
17:36:13 <alistarle> Sure
17:37:41 <knikolla> #topic Open Floor
17:38:12 <knikolla> oops, Bug Duty first :)
17:38:18 <knikolla> #topic Bug Duty
17:38:48 <knikolla> There were a few reported bugs last week
17:38:55 * bnemec notes that meetbot has an undo command
17:39:15 <knikolla> ooo, thanks!
17:39:33 <knikolla> #link https://bugs.launchpad.net/keystone/+bug/1878938
17:39:33 <openstack> Launchpad bug 1878938 in OpenStack Identity (keystone) "System role assignments exist after system role delete" [Undecided,New]
17:40:00 <knikolla> a quick check at the code shows that Role_id isn't a foreign key in either normal assignment or role assignments
17:40:31 <knikolla> are we doing the cleanup in code instead of cascading delete?
17:40:45 <knikolla> or is it because we define them as separate backends?
17:41:04 <knikolla> them = role_backend and assignment_backend
17:41:15 <cmurphy> if they're not in the same backend then it is supposed to be handled with notifications
17:41:25 <cmurphy> which are easy to forget
17:42:38 <knikolla> i see.
17:42:50 * knikolla needs to look at how they're implemented since I haven't played much with them.
17:44:18 <knikolla> cmurphy is covering this week, anyone volunteering for next?
17:44:53 <vishakha> I can take for the next week
17:45:03 <knikolla> thanks vishakha :)
17:45:46 <vishakha> np
17:46:31 <knikolla> #topic Open Floor
17:47:04 <cmurphy> i had a couple more reviews https://review.opendev.org/726727 https://review.opendev.org/726729
17:48:13 <vishakha> I had some more too :)
17:48:34 * knikolla is failing hard at chairing meetings
17:48:48 <vishakha> #link https://review.opendev.org/#/c/712724
17:48:53 <vishakha> #link https://review.opendev.org/#/c/725634/
17:49:28 <lbragstad> looks like we're having some issues with py35 testing
17:49:38 <lbragstad> i've been noticing a bunch of failures with ksa on master recently
17:49:55 <lbragstad> example: https://review.opendev.org/#/c/727498/3
17:50:51 <knikolla> Could not find a version that satisfies the requirement oslotest===4.2.0
17:51:31 <bnemec> Is py35 even still supported on master branches?
17:51:53 <lbragstad> ksa doesn't have a a tox env for it, but it is part of the zuul jobs
17:55:13 <bnemec> I believe the Victoria unit test jobs are py36 and py38. At least that's what I'm seeing in a project that has been migrated to the victoria template.
17:55:40 <bnemec> But maybe ksa makes broader compatibility guarantees? I know we've done that with pbr at times.
17:56:41 <cmurphy> oh wait i just remembered https://review.opendev.org/721084
17:56:45 <knikolla> https://review.opendev.org/#/c/721093/
17:56:56 <cmurphy> yeah that
17:57:40 <lbragstad> ah
17:58:22 <bnemec> Okay, guess you can't just drop the job then. :-)
17:58:24 <cmurphy> so yes py35 is still supported in ksa master and there is some governance saying that requirements etc should still work for py35 so if it's not we should help fix it
18:00:22 <cmurphy> looks like gmann responded on https://review.opendev.org/727498 and there's some ongoing work to fix it
18:02:54 <lbragstad> so we have to maintain our own constraints for ksa?
18:02:58 <lbragstad> is what it sounds lik?
18:03:00 <lbragstad> like*
18:03:03 <knikolla> let's continue on #openstack-keystone
18:03:10 <knikolla> #endmeeting