13:59:23 <pdeore> #startmeeting glance
13:59:23 <opendevmeet> Meeting started Thu Jul 20 13:59:23 2023 UTC and is due to finish in 60 minutes.  The chair is pdeore. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:23 <opendevmeet> The meeting name has been set to 'glance'
13:59:23 <pdeore> #topic roll call
13:59:23 <pdeore> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
13:59:30 <pdeore> o/
13:59:40 <mrjoshi> o/
14:00:43 <pdeore> abhishek is not going to attend due to some emergency
14:00:54 <pdeore> let's wait for others to join
14:01:02 <croelandt> o/
14:01:36 <pdeore> let's start
14:01:44 <pdeore> #topic release/periodic jobs updates
14:02:01 <pdeore> we have tagged m2 last week, it was got delayed due to random gate failures but finally we could do it as decided..
14:02:10 <pdeore> M3 is 6 weeks from now
14:02:43 <pdeore> and our targets for m3 would be new location apis, sorting locations based on store weight & having missing cli support for all image & metadef apis in OSC
14:03:05 <pdeore> patches are up for review for all these ^ which we are going to see in next topics
14:03:15 <pdeore> Periodic jobs are all green except intermittent TIME_OUTs on fips jobs
14:03:36 <pdeore> moving to next
14:03:38 <pdeore> #topic Important Reviews
14:04:01 <pdeore> As said earlier, we have some important patches up for review,
14:04:17 <pdeore> but there are some random CI failures for almost all of these patches
14:04:39 <pdeore> mostly some cinder related different tempest tests are failing & time outs, not sure how to handle this :/
14:05:03 <croelandt> The good way to do this would be to understand why CIs are always failing with issues unrelated to the patches themselves
14:05:17 <croelandt> but it's hard work, it takes time, and has no direct business value
14:05:35 <dansmith> sorry, I'm here
14:05:39 <pdeore> yeah
14:06:05 <dansmith> fixing CI has no direct business value?
14:06:15 <dansmith> as someone who spends a lot of time fixing CI, that attitude irks me :(
14:06:27 <croelandt> well it has value
14:06:32 <croelandt> it would help us merge patches faster
14:06:36 <croelandt> test features etc.
14:06:54 <dansmith> and the tests aren't usually the buggy thing, FWIW
14:06:55 <croelandt> but I think if we were to go to all our companies and say "hey, could we invest $$$ to not recheck all the time hoping for the best"
14:06:59 <croelandt> they would not be happy
14:07:19 <croelandt> but I might be mistaken!
14:07:22 <croelandt> (I hope so)
14:07:47 <dansmith> we don't fix CI to avoid having to recheck, we should be fixing it to either fix the actual product, or fix our ability to show that the product works instead of letting the customers tell us if it doesn't
14:08:07 <croelandt> yes
14:08:16 <croelandt> but as a dev, I feel a bit powerless when trying to merge a patch
14:08:34 <croelandt> I feel like it's timing out and... not much I can do about it, so I'll click the button
14:08:50 <dansmith> you are power*ful*.. go figure out why it's failing, try to fix it.. you'll learn more about the components involved in the process
14:10:04 <croelandt> well, when it's randomly timing out, it's quite a tough process to even know whether you fixed it
14:10:07 <dansmith> anyway, we should move on
14:10:08 <pdeore> but these time outs are also for different jobs everytime :/
14:10:19 <pdeore> :)
14:10:29 <dansmith> pdeore: which shows that they're all related
14:10:42 <dansmith> pdeore: yesterday your location patch was failing for reasons related to your code
14:10:47 <dansmith> looks like you've updated it?
14:10:54 <pdeore> yeah i have updated it
14:11:01 <croelandt> dansmith: now I'm gonna end up bothering you next time there is a failure so you can walk me through your debugging process :)
14:11:41 <dansmith> croelandt: as long as you're putting forth a real effort and not asking me for an answer, that's fine.. there are lots of people to lean on in that regard
14:12:07 <croelandt> good, maybe I'm not that powerless after all \o/
14:12:23 <croelandt> but anyway, I was not implying it's useless to work on the CI
14:12:27 <croelandt> just to be clear
14:12:37 <dansmith> you pretty much said that exactly
14:12:52 <dansmith> let's move on and I can continue being annoyed after the meeting in -glance
14:12:58 <croelandt> ok so it did not come across properly, sorry about that
14:13:08 <pdeore> :D
14:13:25 <croelandt> pdeore: you have the floor :)
14:13:30 <pdeore> ok, so as per the discussion, I have separated out new location api changes in multiple patches and updated as per the suggestions on implemtation part,
14:13:38 <pdeore> #link https://review.opendev.org/c/openstack/glance/+/886749/8   - Location Import task flow
14:13:38 <pdeore> #link https://review.opendev.org/c/openstack/glance/+/881940/22 - Add Location API core changes
14:13:38 <pdeore> #link https://review.opendev.org/c/openstack/glance/+/886947/2   - Fucntional tests for new Add location api
14:13:38 <pdeore> #link https://review.opendev.org/c/openstack/glance/+/882498/14 - New Get location API
14:14:03 <pdeore> I will submit the documentation + api-reference  & version bump patches by tomorrow EOD or Monday
14:15:12 <pdeore> moving to next
14:15:21 <pdeore> #topic OSC & SDK side reviews (mrjoshi)
14:15:36 <pdeore> mrjoshi wants to highlight some OSC & sdk patches which needs attention
14:15:48 <pdeore> mrjoshi, ^
14:16:35 <mrjoshi> There are few patches on the openstack SDK and Openstackclient which needs review
14:17:26 <mrjoshi> #link https://review.opendev.org/c/openstack/python-openstackclient/+/878631 - Add cache commands
14:17:26 <mrjoshi> #link https://review.opendev.org/c/openstack/openstacksdk/+/881939 - Adding Support for image upload
14:17:26 <mrjoshi> #link https://review.opendev.org/c/openstack/python-openstackclient/+/882086 - Adding ``image delete --store`` and ``image import info`` commands
14:18:37 <pdeore> mrjoshi, there are some metadef api related patches as well, right?
14:19:26 <mrjoshi> croelandt, you have a comment regarding raising exception on https://review.opendev.org/c/openstack/python-openstackclient/+/882086 ?
14:20:39 <croelandt> hm
14:20:56 <croelandt> yes, I was wondering if that was the only way of doing this
14:21:01 <croelandt> because error messages can change in the future
14:21:07 <croelandt> and this might end up breaking
14:21:29 <croelandt> can't we check whether multi store is enabled some other way?
14:22:04 <mrjoshi> pdeore, yes #link https://review.opendev.org/c/openstack/openstacksdk/+/858350 , this patch has some review comments on which I'm working and will upload the updated patch by tomorrow
14:22:47 <pdeore> mrjoshi, ok
14:24:48 <mrjoshi> croelandt, I'll look into it if there's any other way
14:25:53 <croelandt> maybe ask Stephen about that
14:25:55 <mrjoshi> but afaik that's how they are doing it in osc , but I'll still confirm it once again
14:25:58 <mrjoshi> ack
14:26:58 <pdeore> mrjoshi, cool, anything else you want to highlight ?
14:27:36 <pdeore> shall we move to open discussions ?
14:28:35 <mrjoshi> yes, there is one question, do we need the output format similar to glanceclient for all the commands
14:29:35 <croelandt> I think it should mostly be consistent with other OSC commands
14:29:37 <pdeore> not sure but I think according to osc rules we have to showcase
14:29:43 <croelandt> is there a particular example you had in mind?
14:29:49 <mrjoshi> yes
14:30:05 <mrjoshi> https://review.opendev.org/c/openstack/python-openstackclient/+/883494
14:30:31 <mrjoshi> So the output for stores-info in osc is displayed in a list-format
14:31:14 <croelandt> yeah I think Stephen is right
14:31:20 <croelandt> we should aim for consistency inside OSC
14:31:26 <croelandt> not between OSC and glanceclient
14:31:29 <mrjoshi> ok
14:31:39 <pdeore> +1
14:31:40 <croelandt> OSC is not going to be a drop-in replacement for glanceclient
14:31:47 <croelandt> well, for interactive use, it will be
14:31:53 <croelandt> but for scripting, no, basically
14:33:27 <mrjoshi> ok
14:34:33 <pdeore> ok, moving ahead
14:34:36 <pdeore> #topic Open Discussions
14:35:19 <dansmith> pdeore: can you explain why the changes you made to your second patch affected the tempest run?
14:35:31 <dansmith> AFAICT, nothing should be plumbed through the external API until the last patch,
14:35:44 <dansmith> yet tempest tests were failing and you made some changes so that they didnt
14:36:16 <pdeore> dansmith, honestly I also not sure
14:36:29 <dansmith> ... seriously?
14:36:46 <dansmith> because I'm thinking if any of your code is actually being called in the current flow,
14:37:10 <dansmith> but is starting a task or something, then any of your new timeouts or new behavior could potentially be related to this code
14:37:36 <dansmith> so how do you justify the changes you made? Looks like you removed something from the response body and maybe added or changed a result code to 202?
14:38:09 <dansmith> potentially the latter might make a client library stop (or start) waiting for something I guess, but that could certainly affect the overall thing
14:40:05 <pdeore> yeah earlier as decided i was returning the updated location url & the validation data since the update location operation was sync but after moving to async, we can not return the same, hence 202
14:40:48 <dansmith> right, but nothing should be calling this code yet, other than unit/functional tests, so I don't see how those changes would have fixed the failures we saw before
14:42:18 <pdeore> dansmith, need to verify it again, may be earlier failure was not related to my changes
14:43:06 <dansmith> kinda hard to imagine they weren't related since they all seemed to involve image ops, but... okay
14:43:30 <dansmith> ... BasicOperationsImagesTest
14:45:36 <pdeore> will check it again ..
14:47:16 <pdeore> anyone has anything else to discuss?
14:48:16 * croelandt has nothing
14:48:38 <mrjoshi> nothing from me
14:49:07 <pdeore> ok, then let's conclude for today !
14:49:20 <pdeore> Thanks everyone for joining!!
14:49:44 <pdeore> #endmeeting