Thursday, 2021-06-03

*** kota_ has joined #openstack-meeting01:23
*** carlotronics has quit IRC03:20
*** carlotronics has joined #openstack-meeting03:24
*** carloss has quit IRC03:40
*** carlotronics has quit IRC03:56
*** manub has joined #openstack-meeting04:21
*** soniya29 has joined #openstack-meeting04:40
*** abhishekk has joined #openstack-meeting04:52
*** soniya29 has quit IRC05:04
*** soniya29 has joined #openstack-meeting05:19
*** soniya29 has quit IRC05:31
*** soniya29 has joined #openstack-meeting05:32
*** soniya29 has quit IRC05:43
*** soniya29 has joined #openstack-meeting05:43
*** ralonsoh has joined #openstack-meeting06:01
*** slaweq has joined #openstack-meeting06:16
*** slaweq has quit IRC06:57
*** tosky has joined #openstack-meeting07:20
*** rpittau|afk is now known as rpittau07:34
*** yasufum has quit IRC08:10
*** Luzi has joined #openstack-meeting08:52
*** kota_ has quit IRC09:01
*** kota_ has joined #openstack-meeting09:12
*** jbadiapa_ has joined #openstack-meeting09:19
*** kota_ has quit IRC09:20
*** abhishekk has quit IRC09:24
*** jbadiapa has quit IRC09:24
*** soniya29 has quit IRC09:45
*** osmanlic- has joined #openstack-meeting10:14
*** osmanlicilegi has quit IRC10:17
*** M0nk3Ee has quit IRC10:18
*** M0nk3Ee has joined #openstack-meeting10:19
*** rubasov_ has joined #openstack-meeting10:21
*** bauzas has quit IRC10:23
*** bauzas has joined #openstack-meeting10:23
*** rubasov has quit IRC10:24
*** armstrong has joined #openstack-meeting10:32
*** soniya29 has joined #openstack-meeting10:34
*** soniya has joined #openstack-meeting10:57
*** soniya29 has quit IRC10:57
*** soniya29 has joined #openstack-meeting11:15
*** soniya has quit IRC11:20
*** osmanlic- has quit IRC11:20
*** osmanlicilegi has joined #openstack-meeting11:20
*** carloss has joined #openstack-meeting11:23
*** hemna has quit IRC11:29
*** soniya29 has quit IRC11:43
*** soniya29 has joined #openstack-meeting11:43
*** hemna has joined #openstack-meeting11:46
*** soniya29 has quit IRC11:51
*** h_asahina has joined #openstack-meeting12:30
*** Luzi has quit IRC12:32
*** soniya29 has joined #openstack-meeting12:35
*** masazumi_ota has quit IRC12:44
*** armstrong has quit IRC12:52
*** soniya has joined #openstack-meeting13:06
*** soniya29 has quit IRC13:13
*** manub has quit IRC13:13
*** abhishekk has joined #openstack-meeting13:44
*** Steap has joined #openstack-meeting13:47
*** rosmaita has joined #openstack-meeting13:51
*** armstrong has joined #openstack-meeting13:52
*** jokke_ has joined #openstack-meeting13:59
abhishekk#startmeeting glance14:00
opendevmeetMeeting started Thu Jun  3 14:00:03 2021 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
abhishekk#topic roll call14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
jokke_o/14:00
opendevmeetThe meeting name has been set to 'glance'14:00
abhishekk#link https://etherpad.openstack.org/p/glance-team-meeting-agenda14:00
abhishekko/14:00
dansmitho/14:00
abhishekklets wait couple of minutes for others to show14:00
rosmaitao/14:01
abhishekkI think Steap will join us soon, till then we can start with the updates14:01
abhishekk#topic release/periodic jobs update14:01
abhishekkM2 is 6 week away14:01
abhishekkwe are going to target at least 2 main specs in this period14:02
abhishekkwhich we will discuss in next topic14:02
*** rajivmucheli has joined #openstack-meeting14:02
abhishekkPeriodic jobs all green for straight 4th week14:02
rosmaita\o/14:03
abhishekkyes \o/14:03
abhishekkno timeouts at all14:03
jokke_nice14:03
abhishekkcool, lets move to next topic14:04
Steapo/14:04
abhishekk#topic Deadlines and review volunteers14:04
abhishekkAs decided/discussed in last week, we will be finalizing deadlines for 2 specs14:04
abhishekk1. Unified quota spec14:05
abhishekkThe spec is owned by dansmith14:05
abhishekkSpec is approved in this week and implementation patches are up for review14:05
abhishekkI am Expecting to be completed - M2 - 1 week i.e. 1 week before Milestone 214:06
abhishekkVoluntary reviewers: abhishekk, Steap (as Steap agreed to help us on reviews)14:06
abhishekkwe need one additional voluntary core reviewer for this14:07
dansmithcan I volunteer rosmaita or does he have to do it? :)14:07
rosmaitayou can volunteer me14:07
abhishekkAny one up for volunteer from rosmaita or jokke_ ??14:07
dansmithseems natural to have the spec +2ers be the code reviewers14:08
abhishekkcool, then jokke_ will be standby reviewer14:08
abhishekkyes14:08
abhishekkIn case one of the voluntary core is not available then standby core needs to step up14:09
abhishekkdansmith, as a owner are you comfortable with deadline decided?14:09
dansmithsure, the only thing that isn't up yet is docs14:09
dansmithwhich I need to get going on now that we have settled all the design and behavior14:10
abhishekkack, so 1st one is final14:10
abhishekkLets move to 2nd one14:10
abhishekkCache API, Move cache operations under glance API14:10
abhishekkOwner is jokke_14:11
abhishekkSpce is already approved by 2 cores, dansmith and jokke_14:11
abhishekkI need to come up with lite-spec for glanceclient changes14:11
abhishekkVoluntary reviewers:14:11
abhishekkI am considering dansmith and Me as a primary reviewers for this spec14:12
dansmithsure14:12
abhishekkgreat14:12
abhishekkSteap, and rosmaita will be on standby for the same14:12
dansmithcan we go ahead and merge the spec? there's not much code up, so I assume merging the spec will allow that to proceed14:12
abhishekkSteap, also has better knowledge of glance-cache so his inputs will also help us14:12
* Steap has got to sit down and read more patches14:13
abhishekkdansmith, yes, I will approve it after the meeting14:13
dansmithcool14:13
abhishekkExpected to be completed - M2 - 1 week14:13
abhishekkjokke_, are you comfortable with the deadline?14:14
jokke_I'll likely need help figuring out how to test this, but the code itself is going to be pretty straight forward14:14
abhishekkcool, we can work on testing part14:15
dansmithit should be easy to test14:15
rosmaitashould probably add tempest tests for the new API and then they can be proposed as recommended items for interop14:15
dansmithjust looking at tempest/api/image/v2/test_images should be pretty instructive, but I can help with that14:15
dansmithrosmaita: yep, noted in the spec :)14:16
abhishekk++14:16
rosmaitaguess you can tell that i am behind on my reviewing14:16
abhishekk:D14:16
jokke_rosmaita: that's IMO for next cycle as it's planned EXPERIMENTAL for this cycle14:16
abhishekkNo, rosmaita we are grateful for your efforts in glance14:16
abhishekkSO, apart from these priorities specs we also need to keep reviewing other patches as well14:17
abhishekkkindly don't forget that :D14:17
dansmithso one related thing,14:18
dansmithI think it would be nice if we're adding new APIs (the cache ones) to make them use a modern policy enforcement14:18
abhishekkAlso, each week we will discuss the progress of the work14:18
jokke_dansmith: I think we need to policy it both ways, no?14:19
dansmithso I wonder if it's worth stacking a refactor of the cached_images enforce under the actual patch to add those new APIs?14:19
abhishekkdansmith, If the new policy enforcement framework is up, running and approved until then there is no issue14:19
dansmithabhishekk: well, right I'm just asking about trying to dovetail those two efforts14:20
dansmithI'll have to go look at what cached_images does now I guess14:21
dansmithI think it was just a single policy rule with no details such that you grant all or nothing to some role14:21
abhishekkjokke_, what do you mean by both ways?14:21
dansmithabhishekk: in your spec you called out the new rules, so I guess when we see the code for the api bit to use those rules we can go from there14:22
jokke_dansmith: if you end up playing around with it, just that you know. Currently the code is under api/v2/, but the API itself is exposed through the cahcemanagemnt middleware that works together with the cahing middleware. It's bit cumbersome, but that's how you can enable it for poking around14:22
jokke_abhishekk: I guess we need to have both checks, legacy glance policy and rbac checks for those endpoints14:23
dansmithI don't know what that means14:24
abhishekkjokke_, we don't need special arrangement for that, if rbac is disabled then it will enforce the policy in legacy format14:24
jokke_dansmith: so the two middlewares needs to be in your paste pipeline for that current cache management API to show up14:25
dansmithI mean the policy thing14:26
abhishekkI think there is some confusion here with rbac and legacy policy14:27
abhishekkjokke_, do you mean we need to test the same with rbac as well as legacy policy enforcement?14:28
jokke_dansmith: so I think the new policy keys makes sense to be enforced at the API, then I just need to figure out how to work around so the old and new policies do not break eachother14:28
jokke_so likely easiest is to move the policy enforcement to the middleware where the API is exposed too to avoid either execution path going through both of them14:29
dansmithI guess I need to look at this closer14:29
jokke_abhishekk: yeah, I think it would be very wrong of us to implement new API endpoints and not take the rbac work into account during the implementation14:30
abhishekkjokke_, ack, but I think we don't need to follow onion layer for these APIs for some reasons14:31
dansmithyeah, sounds like we agree on the goal at least14:31
abhishekkI mean for the new cache APIs14:31
dansmiththis API seems like a good one to have all the policy enforced at the api layer, which might already be the case, but needs some rbac love14:31
dansmithimplementing it all in middleware seems wrong to me, but I need to look and see how that's all done I guess14:32
jokke_abhishekk: I thought it was agreed already ages ago that we avoid adding anythin we don't strictly need to the onion hell14:32
abhishekkok, I will keep the spec on hold till then14:32
abhishekkI would like to explain this policy stuff with rbac in the spec14:33
jokke_dansmith: so the problem is the middleware is exposing the current api which is moving to the api/v2/mapper14:33
jokke_dansmith: we're planning to deprecate the cachemanagement middleware, so while it's deprecated it still needs to enforce it's current policies14:33
jokke_but as we agreed to put new clearly defined policy keys in place we need to avoid overlapping those two14:34
dansmithdid the old cachemanage hit APIs implemented in middleware?14:34
dansmithI had assumed it twiddle the db directly14:35
jokke_dansmith: correct the cachemanagement middleware injected it's api endpoints14:35
jokke_that's why we are refactoring this to clean it up14:35
dansmithright, but.. I didn't realize the manage tool hit those I guess14:35
dansmithso the spec doesn't very clearly articulate that existing apis are going to be moving, and the one code patch that is up just adds new ones,14:36
dansmithso I guess that's why I failed to grasp the moving aspect14:36
rosmaitai missed that part as well14:36
dansmithI'm still not sure what that has to do with what we do for policy though14:36
jokke_yeah, since few cycles ago, it had something to do about getting rid of registry and v1 api that changed it in a way that poking stuff directly got painful14:37
dansmithjokke_: do you have more code for this sitting in the wings that you could push up to better show what all is going on?14:39
jokke_dansmith: they are sharing the functional code, and I'm pretty sure the old policies for it are enforced quite deep in that code. So to be able to introduce the policy keys and enforce the at API layer we need to make sure we don't get hit by the old policies down in the chain but also make sure they still get enformced in the middleware is in play14:39
abhishekkhttps://review.opendev.org/c/openstack/glance/+/62609714:39
abhishekkthis was the code to fix cache-manage when v1 was removed14:40
jokke_dansmith: no, I literally whipped that one patch for abhishekk to have an idea how we could consolidate the functionality under one /v2/cache endpoint14:40
*** rajivmucheli has quit IRC14:40
dansmithokay14:40
abhishekkhttps://review.opendev.org/c/openstack/glance/+/626097/5/glance/api/v2/cached_images.py14:40
abhishekkThis is the existing policy manage_image_cache jokke_ is talking about14:41
dansmithright14:41
*** soniya has quit IRC14:41
abhishekkso this is also injected at API side I guess14:41
dansmithwell, this _enforce method is what I was concerned about earlier:14:42
dansmithself.policy.enforce(req.context, 'manage_image_cache', {})14:42
dansmiththis is one policy element for the whole thing with no target,14:42
dansmithwhich means you can delegate cache management to a role, but with no control beyond that14:42
abhishekkack14:42
jokke_dansmith: yup, that's why we discussed about splitting that policy to individual components.14:43
dansmithfor things like queue_image we should be passing the ImageTarget there so you can allow people to cache their own images, but not others (if that's what you want)14:43
dansmithjokke_: it's more than that though14:43
dansmithbut that's an important part, of course14:43
abhishekkSo definitely spec need some additional information14:43
dansmithfor the rbac part that would be good, yeah,14:44
abhishekkCan either of you comment on the spec, I will update it then14:44
dansmithbut abhishekk maybe you can put more detail in there too about the middleware->api spec?14:44
dansmither, s/spec?/part/14:44
abhishekkyes14:44
dansmithcool14:44
jokke_dansmith: basically the assumption has been as it needs to be done node by node basis that all cache management has been done by admin or admin-like operator responsible for the cache management in the cloud (In reality very little by hand management happens anywhere I know of)14:44
dansmithright, but the point of rbac is to allow for less-than-god-like admins to manage certain spheres of responsibility14:45
jokke_dansmith: which i why I said we need to take that into account for this work14:45
jokke_would be very wrong of us to make this new API endpoint and not implement it with rbac in mind from get go14:46
dansmithI think we're agreeing...?14:46
abhishekkOk, I will update the spec with this14:46
abhishekkwe agreed :D14:47
abhishekkMoving to next topic now14:47
abhishekk#topic Metadef project scope implementation14:47
abhishekkShould we start parallel with policy refactoring?14:47
abhishekkMetadef has 5 to 6 APIs which are pending for project scope implementation14:48
jokke_dansmith: I think that's something at least I just assumed as impementation detail rather major design aspect ... Just expecting that all new API work we do needs to take rbac into consideration like we just assumed that policies needs to be taken into account before without necessarily specifically calling it out in a spec ;)14:48
abhishekkand we need to complete project scope for glance in this cycle14:48
dansmithabhishekk: are you talking about fixing some metadef CRUD APIs so they can be safe to allow project people to manage?14:48
dansmithjokke_: okay, well, the spec is kinda for level-setting assumptions, so... :)14:49
abhishekkyeah14:49
dansmithabhishekk: I'm not sure that's worth the effort unless there's someone that is asking for it14:49
abhishekkI have one associate who is willing to work on this metadef part14:49
dansmithis someone asking for it? it sounded like 99% of people just leverage the inbuilt metadefs for things like horizon, and one entity spoke up (CERN) about updating them, but they were assuming admin-only anyway14:50
abhishekkdansmith, nope no one is asking but its a target given to at least complete implementation of project scope for this cycle14:51
dansmithokay, but if we just delcare that this is not a project-scope-able API then ... it doesn't matter right?14:52
jokke_My biggest concern with the whole rbac picture atm. is that when you turn that on we loose our 'admin' and we have lots of things that assumes admin overwrites and adminnes baked into our API. Like with just project scope implemented Glance will be very very broken service with rbac turned on14:52
dansmithwell, that's why it's a big effort (for all projects) and why they pay us the medium bucks to fix it right? :)14:53
jokke_and none of that translates to project admin14:54
abhishekk5 minutes, we can revisit this next week14:55
abhishekkwith more information14:55
abhishekk#topic Open discussion14:55
abhishekkis something missed?14:56
abhishekkwhay bot is not working ?14:56
abhishekkso bots are not working since the begging14:57
rosmaitalooks like it crashed after #startmeeting14:57
dansmithlooks like it started the meeting,14:57
dansmithbut yeah14:57
dansmithcrashed setting topic maybe :)14:57
abhishekkanything for open discussion?14:57
rosmaitabtw, i'll be away all next week, so will miss the meeting :)14:57
jokke_abhishekk: well it reported starting meeting ... might be that the oftc services are not exact compatible for topic setting or something14:57
jokke_fungi: ^^14:57
abhishekkI think so14:58
abhishekkI think some1 should have noticed it earlier14:58
jokke_Monday is Bank Holiday here, so I'll be around 4 days next week14:58
fungiyes, if you followed the announcements on the service-discuss ml, the meetbot can't currently alter channel topics14:58
fungiwe're rewriting the bot to interact with chanserv via privmsg to do it14:58
abhishekk:D, thank you for the update14:58
abhishekkjokke_, cool, have a nice weekend14:59
abhishekkOk, time is up15:00
abhishekkthank you all15:00
jokke_thanks!15:00
abhishekk#endmeeting15:00
opendevmeetMeeting ended Thu Jun  3 15:00:19 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:00
opendevmeetMinutes:        http://eavesdrop.openstack.org/meetings/glance/2021/glance.2021-06-03-14.00.html15:00
opendevmeetMinutes (text): http://eavesdrop.openstack.org/meetings/glance/2021/glance.2021-06-03-14.00.txt15:00
opendevmeetLog:            http://eavesdrop.openstack.org/meetings/glance/2021/glance.2021-06-03-14.00.log.html15:00
*** rosmaita has left #openstack-meeting15:00
*** carlotronics has joined #openstack-meeting15:07
*** abhishekk has quit IRC15:08
*** abhishekk has joined #openstack-meeting15:08
*** abhishekk has quit IRC15:08
gagehugo#startmeeting security15:11
opendevmeetMeeting started Thu Jun  3 15:11:28 2021 UTC and is due to finish in 60 minutes.  The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot.15:11
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:11
opendevmeetThe meeting name has been set to 'security'15:11
gagehugoo/15:12
*** Steap_ has joined #openstack-meeting15:12
fungiohai15:13
*** erlon has quit IRC15:13
*** Steap has quit IRC15:14
gagehugo#link https://etherpad.opendev.org/p/security-agenda  agenda15:14
gagehugoapologies for the late start15:15
gagehugo#topic Folding the openstack-security ML into openstack-discuss15:16
fungiso... i go through the moderation queue for it daily and discard spam15:16
gagehugofungi: I guess we haven't really been using the openstack-security ML?15:16
fungibut looking back at the archives there's not been a single post to it in over a year15:16
fungianyway what we've done with other lists is to send a message to it saying it's being closed down, then delete the configuration for it (leaving the archives intact for posterity), and we add mail address aliases to direct future messages to openstack-discuss15:19
gagehugoI think that is fine15:19
fungii'm happy to take care of all that as long as we have consensus15:19
gagehugoone ML to rule them all15:20
fungiin that case i'll send a message to the openstack-security ml this week saying we're shutting it down15:20
fungiand separately we'll want to use codesearch.o.o to find references to that ml and update them to point to the openstack-discuss ml (saying to use [security-sig] in the subject line)15:20
*** armstrong has quit IRC15:21
gagehugook15:23
gagehugo#topic Need to update all the IRC references for security-sig15:24
gagehugoThis is likely just the same thing, using codesearch.o.o to find/replace any irc references to point to the new ones15:25
gagehugo#topic open discussion15:26
gagehugofungi: any other updates?15:27
funginope, none from me. i sent a batch of reminders to the discuss ml about outstanding public vulnerability reports15:32
fungithere's been some movement on a few, so i'll try to keep doing that15:32
fungithough others are also free to take a turn if they want15:33
*** Steap_ has left #openstack-meeting15:33
fungieventually it would be great if the people taking bug triage shifts on the individual projects started to include status for outstanding public vulnerability reports in their own periodic bug status reports to raise visibility, but i'm not sure how to get them to do it. i've tried to suggest it and get the opinion i'm being ignored15:34
gagehugoLol15:37
gagehugoDo all the projects have bug triage shifts?15:37
funginot all, but the ones who also tend to have a lot of vulnerability reports do15:40
fungithe rotating "bug czars/tsars" or whatever fancy titles they like to give them to make it seem like it's not janitorial drudgery ;)15:41
gagehugohmm ok15:45
gagehugoI need to hop on another call, thanks fungi as always15:45
gagehugo#endmeeting15:45
opendevmeetMeeting ended Thu Jun  3 15:45:54 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:45
opendevmeetMinutes:        http://eavesdrop.openstack.org/meetings/security/2021/security.2021-06-03-15.11.html15:45
*** armstrong has joined #openstack-meeting15:45
opendevmeetMinutes (text): http://eavesdrop.openstack.org/meetings/security/2021/security.2021-06-03-15.11.txt15:45
opendevmeetLog:            http://eavesdrop.openstack.org/meetings/security/2021/security.2021-06-03-15.11.log.html15:46
fungithanks gagehugo!15:46
*** armstrong has quit IRC15:55
*** armstrong has joined #openstack-meeting16:04
*** armstrong has quit IRC16:12
*** rpittau is now known as rpittau|afk16:12
*** armstrong has joined #openstack-meeting16:15
*** ralonsoh has quit IRC16:24
*** kota_ has joined #openstack-meeting17:11
*** kota_ has quit IRC17:19
*** ralonsoh has joined #openstack-meeting19:16
*** armstrong has quit IRC20:22
*** armstrong has joined #openstack-meeting20:22
*** ralonsoh has quit IRC20:28
*** armstrong_ has joined #openstack-meeting20:31
*** armstrong_ has quit IRC20:37
*** armstrong has quit IRC20:44
*** kota_ has joined #openstack-meeting20:45
*** armstrong has joined #openstack-meeting21:40
*** armstrong has quit IRC21:43
*** kota_ has quit IRC21:52
*** armstrong has joined #openstack-meeting21:57
*** eharney has quit IRC21:57
*** armstrong has quit IRC21:57
*** armstron1 has joined #openstack-meeting22:08
*** armstron1 has quit IRC22:10
*** yamamoto has quit IRC22:45
*** tosky has quit IRC23:00
*** masazumi_ota has joined #openstack-meeting23:29

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!