14:00:04 #startmeeting glance 14:00:05 Meeting started Thu Feb 18 14:00:04 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:07 #topic roll call 14:00:09 The meeting name has been set to 'glance' 14:00:14 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:16 o/ 14:00:36 o/ 14:00:52 Lets wait couple of minutes for others to join 14:03:04 Looks like just two of us 14:03:19 There's Brian 14:03:24 yep 14:03:27 lets start 14:03:41 #topic release/periodic jobs update 14:03:52 sorry i'm late 14:04:01 no worries 14:04:06 Final release of non-client libraries - 2 weeks 14:04:20 One patch is open which seems good to get in 14:04:21 https://review.opendev.org/c/openstack/glance_store/+/775497 14:05:39 Before next meeting I will prepare release note patch and then following Monday will propose the release patch 14:06:31 kk, lets have a pass over the bugs as well and just make sure we get any criticals/quick ones smacked down before releasing 14:06:53 dansmith, not able to see the updates as well as topic updates in the heading 14:07:03 is it same for jokke and rosmaita ?? 14:07:23 I see 'em 14:07:46 here now 14:07:47 netsplit I guess 14:07:53 ahh 14:08:13 jokke, right, good to go through bugs as well 14:08:37 Milestone 3 - 3 weeks away 14:08:54 Bunch of patches are open for review 14:09:05 and not enough time 14:09:16 we also need to consider delays in gate 14:09:57 Kindly start reviewing open patches 14:10:12 Periodic jobs - Couple of failures due to fix merged in glance_store 14:10:21 Patch to skip test - https://review.opendev.org/c/openstack/glance/+/776406 14:10:43 We have a fix as well but that will not work unless glance_store is released and available to use 14:11:06 Everything is described in the commit message and related bug 14:11:32 kk 14:11:33 any questions? 14:12:00 ok, moving ahead 14:12:08 #topic Critical reviews 14:12:16 Glance Secure rbac 14:12:24 This is a top priority for us 14:12:34 patches are up, functional tests are up as well 14:13:02 And I am suggesting that we should get this done as EXPERIMENTAL in this cycle 14:13:32 There is a way to use deprecated policies 14:14:10 So we will not mark it stable if and unless everything is working as expected 14:14:49 ++ 14:14:50 Any inputs/concerns/suggestions ? 14:15:05 Lets take the Experimental into the patches and reviews then 14:15:29 should not be a big change and I think at this stage it's good idea 14:16:03 cool, I will update the patches to mark those as experimental 14:16:19 lbragstad, may be busy with other work, so I will take this up 14:16:38 what does this mean from the operator perspective? 14:17:09 i guess we mention in release notes and say turn on enforce_scope in oslo.policy at your own risk? 14:17:21 yes 14:17:27 rosmaita: that to use this they need to specifically enable it and for audit purposes it's flagged as experimental for this release 14:17:32 and report if they found any issues 14:18:10 ok, that makes sense 14:18:39 great 14:19:05 o/ here now if there is anything specific to discuss 14:19:13 #action abhishekk to update secure-rbac patches to mention Experimental status 14:19:42 lbragstad, So we are deciding to have secure-rbac as experimental in this cycle 14:19:57 ok 14:20:21 will let you know if any specific help is required 14:20:30 sounds good - thank you for the help 14:20:47 Thank you for your patience and work 14:21:03 moving ahead 14:21:04 Task show API 14:21:18 #link 14:21:18 https://review.opendev.org/c/openstack/glance/+/763739 (base patch) 14:21:27 Needs reviews 14:21:35 I have also posted client changes for the same 14:21:53 and I posted a tempest test 14:21:59 #link https://review.opendev.org/c/openstack/python-glanceclient/+/776403 14:22:08 I think I'm mostly good on that series, I guess I have one more PS to look at that I haven't yet 14:22:22 somehow I didn't notice you refreshed it 14:22:24 #link https://review.opendev.org/c/openstack/tempest/+/775679 14:22:42 Tempest test for new API ^^ 14:22:46 dansmith, ack 14:23:20 Distributed image import 14:23:29 Spec - https://review.opendev.org/c/openstack/glance-specs/+/774097 14:24:08 Spec was in merged conflict, so please put your vote again 14:24:15 Implementation https://review.opendev.org/c/openstack/glance/+/770682 (base patch) 14:25:13 As decided in weekly meeting two weeks before, we are opting for image_property solution this cycle and then make improvements to use location in next cycle 14:25:50 I am hoping to have everyone on board with approach 14:26:19 quick question 14:26:33 shoot 14:26:39 did we merge dan's patch making os_glance* a restricted namespace for properties? 14:26:46 yes 14:26:56 and the tempest test for that just merged 14:27:16 and i thought i saw code somewhere so that some of these are hidden for non-admin user image-show ? 14:27:54 you might have seen that in implementation patch 14:27:56 https://review.opendev.org/c/openstack/glance/+/769976/12/glance/api/v2/images.py 14:28:02 check hidden_properties there yeah 14:28:24 ok, cool 14:28:54 https://review.opendev.org/c/openstack/glance/+/769976/12/glance/api/v2/images.py#1456 14:28:54 line 1456 14:28:57 :) 14:29:01 :d 14:29:10 tests in here: https://review.opendev.org/c/openstack/glance/+/769976/12/glance/tests/unit/v2/test_images_resource.py for that 14:29:43 there are also other bunch of open reviews 14:30:16 So requesting everyone to put their reviewers hat on 14:30:56 that's it for today 14:31:04 Moving to Open discussion 14:31:10 #topic Open discussion 14:31:33 i want to go back to the glance_store change that broke tests 14:31:48 I just discussed that with rajat 14:31:48 ok 14:31:50 we have the periodic job that checks glance_store-tips 14:31:53 and I think we have a better plan 14:32:05 i mean about catching this in the first place 14:32:13 rosmaita, yes and there only I have managed to catch this failure 14:32:32 we have the glance_store tips jobs set up so you can "check experimental" and run them 14:32:32 https://zuul.openstack.org/build/0875b94694ee4a408e5a210ea720936b 14:33:00 i guess the problem is that you have to do this on a glance patch, not a glance store patch 14:33:09 right 14:33:16 right 14:33:22 glance_store could have a glance job that uses it unreleased though 14:33:27 I can write one of those if you want 14:33:28 but i think the glance_store zuul.yaml can refer to jobs defined in glance zuul.yaml 14:33:33 sure 14:33:51 yeah, that would be good 14:34:11 we need to have some glance_store gate that runs against glance master, i think 14:34:25 clearly :) 14:35:34 I think hanving glance_store tested has been in general a topic since the lib was broken off from glance 14:36:10 that reminds me, we also needs to fix broken requirements job on stable branches 14:36:30 btw, dansmith you should review the glance_store tips jobs in glance zuul.yaml, at some point i was wondering if i had set them up correctly 14:36:41 but we do run tempest tests as part of glance_store gating ... I guess that's issue was just something tempest is not testing 14:36:41 jokke, I think you have enough idea about what to fix 14:37:03 jokke: these were functional tests in glance 14:37:08 so no tempest 14:37:19 we need to run glance's functional against unreleased glance_store 14:39:41 and we do have job which runs again cinder multi store but this issue was for single store 14:40:08 well, unless that runs with unreleased glance_store it won't matter, and didn't in this case right? 14:40:21 * dansmith looks 14:40:43 dansmith, hmm 14:40:45 yeah, only released glance_store 14:40:45 right 14:43:28 anything else? 14:43:39 yeah any test job that is not part of the glance_store [check, gate, tips] is just taking the g_s from pypi 14:44:51 I think only tips jobs are running on glance_store master 14:45:12 i think that's right 14:45:15 every other check/gate downloads it fron pypi 14:45:33 yeah, but we can tell a job to get it from master 14:45:44 well the glance_store check andgate jobs are for sure running against master, gerrit ain't pushing these patches on the lib pulled from pypi 14:46:26 yes that is correct 14:46:37 zuul can run glance jobs against glance_store master with a patch applied if you tell it to 14:46:42 use_from_lib? 14:46:49 i just remembered the problem with the tips job for glance_store, it fails after something bad has already merged into glance_store 14:46:51 in zuulv2, required_projects 14:47:11 which i guess is helpful as an advance warning before we release glance_store 14:47:20 rosmaita: this is why the glance_store should run glance master with the proposed patch against glance_store, even for functional tests since they depend on it 14:47:20 ++ 14:47:39 i agree 14:47:57 dansmith: last time it was discussed, it was generally frowned upon to test with unreleased dependencies. That's why those tips jobs were created so we can get heads up when something is breaking before release 14:48:02 gorka has cinderlib's tox.ini set up to always run against cinder master, maybe we need to do that here 14:48:05 and hard gate breakages 14:48:11 jokke: I'm talking about testing glance_store that way not glance 14:48:37 glance should probably *also* have a job that runs against the glance_store master, but it needs to test against released for sure 14:49:15 dansmith: yeah, I was writing nd missed your note of specially referring to running glance functional as part of g_s 14:49:52 the problem with that is, that any change that needs coordination (as in we need something merged to store and then to glance) will be in deadlock 14:50:06 rosmaita, So I have one question about rbac 14:50:16 that's why we have the tip jobs so we can catch these before release time 14:50:29 to mark it as experimental I need to do it in every policy that we are defining right? 14:50:34 jokke, ^ 14:50:48 we should never have something merge to glance_store that needs a matching thing to land in glance at the same time, or vice versa 14:50:55 or justt a releasenote will do? 14:51:01 abhishekk: i am not sure about the logistics of that 14:51:35 rosmaita, ack 14:51:48 is the situation that the known-good-policies (that is, the old ones) will be marked as deprecated, but we want the new ones to be considered experimental? 14:52:10 so we want people in wallaby to use the deprecated ones, but to be ready for the change 14:52:24 I think that's what we want 14:53:10 i think then we need to make it clear in the release notes, and also what the oslo.policy config on the glance-api nodes needs to be 14:53:19 i think the defaults will be fine 14:53:27 but should call them out 14:53:33 abhishekk: easiest way to do that is to add deprecated config option in glance that set to false (by default) overwrites the oslo_policy config. flag that config option enabling Experimental policy feature and allow the oslo_policy to be configured with the new enforcement 14:53:35 we need to check with lbragstad about this, htough 14:54:09 jokke, ack 14:54:51 abhishekk: then once we flag that stable, we can flip it true by default and remove the config option on the following cycle once we don't want people to use the old policy code at all anymore 14:55:17 jokke: that sounds like a good plan 14:56:11 jokke, ack, will work on this solution 14:57:03 that way you don't need to do it on every individual policy 14:57:23 yeah, you don't want to have to annotate every policy 14:57:27 one question 14:57:35 that flag is by default false in oslo policy 14:57:50 so do we need to overwrite it in glance? 14:58:10 i think we do, it gives us a failsafe 14:58:25 cool 14:58:26 so mostly we'll be overwriting False with False, but what the heck 14:58:44 abhishekk: yes because we want to have the experimental feature enablement being very clear decision. Not just that flipping some other config option suddenly turn experimental feature on too 14:59:08 ok 14:59:32 i agree with jokke about this 14:59:40 will ping you if have any doubts 15:00:07 that's all, time's up 15:00:10 thank you all 15:00:15 have a nice weekend 15:00:23 #endmeeting