17:00:04 #startmeeting keystone 17:00:05 Meeting started Tue May 5 17:00:04 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:08 The meeting name has been set to 'keystone' 17:00:31 o/ 17:00:33 o/ 17:00:43 o/ 17:00:47 i almost lost track of time 17:00:50 o/ 17:01:19 o/ 17:01:38 how's everyone? 17:01:47 o/ 17:02:27 pretty good, it's going to be 80F here this weekend 17:02:55 * lbragstad barely knows what day it is 17:03:12 only ~60F here this weekend :( 17:03:41 it's been pretty gorgeous here too for the past few days. 17:03:46 definitely makes working harder. 17:04:47 #topic Announcements 17:05:02 This week is the deadline to request slots for the PTG 17:05:26 End of Day I will go ahead and reserve slots according to the poll 17:05:38 It seems like Thu-Fri is what worked best for us 17:05:52 And those days were pretty open in the ethercal as well, so it should not be a problem 17:06:11 sounds good 17:07:11 How many hours do you think we need? 17:08:36 ~3ish/day? 17:10:28 Sounds about right. There isn't a lot of items on the agenda. 17:11:29 the schedule is in 4 hour blocks so maybe one 4 hour block with a break in the middle, for two days? 17:12:39 Do we want to do separate times per day to maximize availability 17:12:44 as well? 17:13:49 the same time on both days were the only times that had everyone voting yes on the poll 17:14:02 ah ok 17:17:17 We can advertise that if people need to talk to the team, they can show up on IRC and we can jump on a conference call or smth 17:17:34 outside of those times 17:17:43 ++ 17:19:46 okay, i filled the ethercal with 1PM-5PM UTC on Thu and Fri. 17:20:33 +1 17:21:38 alright, in the coming weeks i'll polish up the agenda, so make sure to add items before i start putting them into schedules 17:22:01 #topic Review Requests 17:22:25 #link https://review.opendev.org/#/q/status:open+project:openstack/keystone+branch:master+topic:update-onboarding 17:23:06 These are the patches for updates in the onboarding documents 17:23:30 #link https://review.opendev.org/#/c/725034/ Remove func not in use in test_service_provider 17:25:04 #link https://review.opendev.org/632213 17:25:16 i cleaned up and rechecked ayoung's patch ^ 17:27:11 cmurphy: wonder why that does the html by hand rather than using a flask template 17:28:40 knikolla: hmm i didn't know there was such a thing, feel free to suggest a better way on the review 17:29:30 i'll have a look at it 17:31:51 #topic Bug Duty 17:32:26 I was on bug duty 17:32:32 I don't think I saw any new bugs opened 17:33:27 Next person on bug duty is vishakha 17:33:31 Anyone wants to take after? 17:33:47 Thanks knikolla for the reminder 17:36:54 alright, i'll take it again then 17:36:59 #topic Open Floor 17:37:17 Hi, I implement a first POC of unified limit for glance, based on what was done for nova, and I have some question before submiting the code and the spec to the glance team 17:38:44 First of all, It is mandatory to specify an endpoint_id in oslo_limit configuration part otherwise the enforcer won’t work, I find that surprising to hardcode an ID in glance_api.conf (https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L178), is it expected ? 17:40:58 alistarle: we discussed using service name + region instead of endpoint id but haven't implemented it yet, background on that discussion is here https://review.opendev.org/#/c/666085/ 17:41:25 we'd welcome that contribution 17:41:53 Ok great, I will work on that then in addition to my glance patch 17:42:01 service name + region seems logical to me 17:42:22 another question is who is in charge to setup the initial registered limit ? The service itself ? I see nothing about that in keystone spec or in the nova implementation poc : https://review.opendev.org/#/q/topic:bp/unified-limits-nova+(status:open+OR+status:merged) 17:43:24 currently I have to setup it manually at the same time that creating the service user, but if I omit that, enforcer are failing too 17:44:04 alistarle: in the nova case they were discussing using a keystone-manage/nova-manage command to export limits from nova and import them into keystone, that's not been implemented yet on the keystone side and i'm not sure where they are on the nova side, so for the moment the operator has to do it manually 17:45:28 Hmmm ok, so it must be included at the deployer level maybe, like tripleO/kolla-ansible..., not inside projects right ? 17:46:18 It means that using by default unified limits are complicated, because it require some orchestration in the deployer 17:48:06 i think yes that was where we landed at least to start with, the projects would have to express the registered limits they need and have the operator or deployment tool run a command to register them 17:48:24 you might consult johnthetubaguy or lbragstad who might remember better than me 17:48:46 Ok thanks I will check with them 17:48:57 cmurphy that sounds right 17:49:43 And another question is I understand that unified limit allow customer to consult and ops to set a limit, but what about consulting the current usage ? In nova I understand they will use the placement API for that but in glance there is nothing about limit yet, so should we add new API path only for consulting quota usage ? 17:50:45 Adding a new API path to consult your usage and not the limit seems weird, and making a proxy from glance to keystone to query the limits seems even worse 17:51:34 alistarle: exposing usage will be up to the service, not keystone 17:52:07 i thought the placement API was going to be used by more services than just nova, if glance used it wouldn't that take care of itself? 17:53:15 Hmmm maybe you're right, I didn't think about that, I will deep dive that way 17:53:57 And my last question about something I found, enforcing and creating unified limits require the « system_scope = all » to work, does it mean the glance service account must have this system_scope ? 17:54:38 by default, service account does "only" have the admin role on the service project 17:56:18 creating the limits requires system scope but querying the limits should be doable by anyone regardless of scope 17:57:25 In fact we need to add a system_scope role to the glance user to be able to list other projects limit 17:58:15 otherwise, if in oslo_limit you specify a project to log in, you won't be able to see others project limit, they will only have the registered limit 17:59:26 ah that is true, you will have to give the service user at least the 'reader' role on the system scope 18:00:14 we can continue this at #openstack-keystone 18:00:15 alistarle: feel free to bring us any other questions any time in #openstack-keystone 18:00:18 thanks everyone 18:00:21 #endmeeting