Thursday, 2026-05-14

*** elodilles is now known as elodilles_pto07:49
opendevreviewAbhishek Kekane proposed openstack/glance-specs master: [Spec] Parallel image import  https://review.opendev.org/c/openstack/glance-specs/+/96704608:55
abhishekk#startmeeting glance14:00
opendevmeetMeeting started Thu May 14 14:00:30 2026 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'glance'14:00
abhishekk#topic roll call14:00
abhishekk#link https://etherpad.openstack.org/p/glance-team-meeting-agenda14:00
sakumbha__o/14:00
abhishekko/14:01
pdeore_o/14:01
*** pdeore_ is now known as pdeore14:01
abhishekkPTL is on leave till 1st week of June14:01
abhishekkpdeore: do you have periodic jobs link handy?14:01
pdeore#link https://zuul.opendev.org/t/openstack/builds?project=openstack%2Fglance&project=openstack%2Fglance_store&project=openstack%2Fpython-glanceclient&pipeline=periodic14:02
abhishekkglance-multistore-cinder-import-fips is failing need to have a look at it, rest all are fine 14:02
abhishekk#topic open discussion14:03
abhishekkI have updated parallel import image spec, kindly review it14:03
pdeoreack14:03
abhishekk#link https://review.opendev.org/c/openstack/glance-specs/+/96704614:04
abhishekkI don't have anything else to share14:04
pdeoreplease have a look at the eventlet-removal patches as well14:04
pdeore#link https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22+project:openstack/glance+status:open14:04
abhishekkLets wait 5 minutes if anyone shows14:04
abhishekkack14:04
pdeoreso we are skipping m1 ?14:04
abhishekkyes14:05
abhishekkcan you tell how https://review.opendev.org/c/openstack/glance/+/988112 is related to eventlet?14:05
abhishekk?14:07
pdeoreoh no it's not, I think i accidentally set it's topic to eventlet-removal since it was a fix submitted during fixing rally-uwsgi job failure 14:07
abhishekkack14:07
dansmitho/14:07
abhishekko/14:07
dansmithsorry for being late14:07
dansmithI'll circle back to the spec today14:07
abhishekkno worries, we don't have much for discussion14:07
abhishekkack, thank you!!14:08
abhishekkanything else for discussion?14:08
pdeorenothing from me14:09
dansmithnope14:09
sakumbha__nothing from me14:09
abhishekkUnless we have some important stuff coming up before next meeeting, we will skip that and meet directly week after14:09
abhishekkThank you all for joining!! Have a good day/night!!14:09
abhishekk#endmeeting14:10
opendevmeetMeeting ended Thu May 14 14:10:04 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:10
opendevmeetMinutes:        https://meetings.opendev.org/meetings/glance/2026/glance.2026-05-14-14.00.html14:10
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/glance/2026/glance.2026-05-14-14.00.txt14:10
opendevmeetLog:            https://meetings.opendev.org/meetings/glance/2026/glance.2026-05-14-14.00.log.html14:10
dansmithabhishekk: just a couple more thoughts on the lifecycle of these location rows15:30
dansmithif you really want to just go with what you have then I'll be +2, I'm just thinking about how this will work and be the most useful long-term15:31
dansmithif you think about a local fast/cheap store and a remote/slow/reliable store, the latter could take muuuch longer to upload to than the local one, but it might be nice to be able to access the cheap one while the latter is still in progress15:32
dansmithat least keep that option open for the future and having the right set of state transitions would be ideal15:32
abhishekkdansmith: I will have a look at your suggestion tomorrow morning, the idea sounds good just need to check how complex it will be from implementation point 15:47
dansmithack, I think it will be the same amount of complex, just more reliable accounting15:48
abhishekkqueued - uploading - active in case all_stores_must_succeed is False and queued - uploading - uploaded - active in case it is true (i need to check how this will fit15:49
abhishekkmay be otherway around based on the flag all_stores_must_succeed 15:49
abhishekkwill check and update the spec tomorrow accordingly15:50
dansmithyeah, I guess a little more complicated if the image has to go to active in the middle once one of them succeeds, but that's probably what people would expect anyway15:50
abhishekkyes15:50
dansmithI don't want to make it more complex, but just getting the lifecycle names correct so that we _could_ do that in the future is a good idea I think15:51
dansmitheven if we don't actually make the locations/image go active immediately right now15:51
abhishekkagree, making it right from the start is smart thing to do15:51
dansmithlike queued->uploading->uploaded only/always right now regardless of the flag is the same amount of complexity... making the image/locations go active immediately based on the flag is a little more work, could be done later15:52
abhishekkack, i will check and then update the spec15:52
gmaandansmith abhishek can either of you help/confirm me on the propose tempest scenario test for image cache and assert on the 'hits' field count.https://review.opendev.org/c/openstack/tempest/+/957612/comment/49b5ee70_9e764c42/18:36
dansmithgmaan: yep18:42
gmaanthanks18:42

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