14:02:30 <jokke_> #startmeeting glance
14:02:31 <openstack> Meeting started Thu Jun 13 14:02:30 2019 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:34 <openstack> The meeting name has been set to 'glance'
14:02:38 <smcginnis> o/
14:02:43 <abhishekk> o/
14:04:11 <jokke_> #topic roll call
14:04:12 <jokke_> o/
14:04:15 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:04:24 <davee__> o/
14:04:45 <jokke_> soo short meeting based on the agenda today
14:05:25 <jokke_> #topic release updates
14:06:26 <jokke_> abhishekk: how is our periodic jobs looking, everything still green?
14:06:29 <abhishekk> so we had a glance_store release last week, but it is breaking the glance backward compatibility at the moment
14:06:53 <abhishekk> jokke_, glance_store periodic tips jobs are failing
14:07:30 <jokke_> ok
14:07:47 <abhishekk> jokke_, once we revert this change https://review.opendev.org/#/c/663889/ it will be good to go
14:08:09 <jokke_> #link https://review.opendev.org/#/c/663889/
14:08:14 <abhishekk> or https://review.opendev.org/664865 we need to merge this glance change
14:08:30 <jokke_> #link https://review.opendev.org/#/c/663894/
14:09:06 <jokke_> then we can tag 0.29.1 and remerge the breaking change for 1.0.0 release and fix the glance side
14:09:08 <smcginnis> Do we want the revert, or to fix the tests? I wasn't sure on that.
14:10:45 <jokke_> I'm not gonna be prioritizing anything else before the _store situation is resolved. The change to global requirements to block using 0.29.0 got merged
14:11:03 <jokke_> smcginnis: I think you even +W'd it :)
14:12:41 <abhishekk> in that case we need revert
14:13:00 <smcginnis> I'm just not clear on what approach we want to take. abhishekk's response to my quesiton on Patch Set 3 of https://review.opendev.org/#/c/658960/ made sense, so I'm not sure if we really need to revert or if we just need to fix the failing bits and move on now.
14:13:23 <smcginnis> We can always "unblacklist" if we decide it's actually OK.
14:15:25 <abhishekk> smcginnis, if we want 0.29.0 then we need https://review.opendev.org/664865 and  https://review.opendev.org/#/c/658962 gets merged in glance
14:15:57 <jokke_> I do not want to unblacklist that release. I has no release notes of the breaking behavior and that change I proposed rever for was not supposed to be released as anyhing but major release. This was discussed multiple times over the planning for this cycle and in PTG.
14:16:44 <jokke_> Just the fact that you guys decided to rush the release _and_ not release 1.0.0 as agreed does not make it the right thing to do as consumer perspective
14:17:41 <smcginnis> OK, just making sure we have the plan clearly stated. So we will revert the change, do a bugfix release to get it out there, then later redo the change and update glance and release it again as 1.0.0. Do I have that right?
14:17:48 <abhishekk> yes, actually our intention was to tag 0.29.0 and if any failure happens fix it and release 1.0.0
14:18:00 <jokke_> smcginnis: correct
14:18:49 <smcginnis> OK, approved the revert and the release note, so phase one should be done. :)
14:18:57 <jokke_> so there is nothing preventing us to do 1.0.0-rc1 of glance store and get everything sorted into that after we push the naming change in there and get glance patches ready to go
14:19:21 <jokke_> smcginnis: great, we can tag the 0.29.1 release today if those merges cleanly
14:19:22 <abhishekk> jokke_, yeah, that never touched my mind
14:19:50 <jokke_> then the next thing which is related to that
14:20:44 <jokke_> have we figured out do we actually need the glance milestone release or can we work around that so we can have migrations opened. As that backend->store name change needs a migration for upgrade
14:21:05 <jokke_> which is one of those patches we need to have ready to go
14:21:50 <smcginnis> I have not had the time, but someone should be able to test this locally by making a commit to their local branch with "Sem-Ver: major" in the commit message and seeing if that version check passes.
14:21:53 <abhishekk> so do we need to have migration for this or I can do it in lazy store loading patch?
14:23:23 <jokke_> We need to have the metadata key changed in the DB ... even the feature is experimental we can't just break it without way forward. So I think the cleanest way forward is to have migration for it and move on
14:24:04 <jokke_> And mention in the release notes that if one had multi-store enabled the upgrade will take bit of time
14:24:34 <jokke_> the good thing is that it should be very very quick for everyone who haven't gone into multi-store yet
14:24:46 <abhishekk> so, I will work on migration script tomorrow
14:24:47 <jokke_> as the migration is effectively noop
14:25:33 <jokke_> smcginnis: so updating the constant and including that line in semver should just pass the test cleanly?
14:25:49 <jokke_> sorry, commit message
14:26:06 <jokke_> without any tags involved
14:26:53 <smcginnis> jokke_: I believe so.
14:27:38 <jokke_> I'll give that a try today, if it works, I'll push the patch up and you abhishekk can then depend on that with the migration script patch and we can forget the milestone releases and that part of the doc
14:27:53 <abhishekk> ack
14:27:56 <jokke_> or I will submit the doc clarification with the patch
14:28:02 <abhishekk> cool
14:28:09 <jokke_> that gets us moving forward
14:28:35 <jokke_> If that works it will make the life with migrations so much easier
14:29:03 <jokke_> smcginnis: ^^ that being the case I owe you some beverages when we meet next time :P
14:29:20 <smcginnis> jokke_: After I buy you one. :)
14:29:46 * jokke_ can foresee wet night ahead
14:30:02 <jokke_> ok, lets move on if that's all around our releases
14:30:48 <jokke_> #topic default tox environment
14:31:03 <jokke_> Brian put this into the agenda
14:31:23 <jokke_> #link https://review.opendev.org/#/c/664475/1/tox.ini@3
14:31:26 <smcginnis> There's some information on this in the Train goal. See last sentence in this section: https://governance.openstack.org/tc/goals/train/python3-updates.html#stretch-goals
14:32:52 <abhishekk> so last sentences is advising to remove py34 and py35 environments
14:33:09 <jokke_> I think I expressed my concern about the py3 versions we flag as well earlier when these were changed and the drop of 3.5 was current and never got any clarity for that
14:34:26 <jokke_> so we indeed should include the py37 nad I guess default to that as well?
14:34:50 <smcginnis> The general consensus I've seen so far is just adding py37 tests is enough to declare 3.7 support in the setup.cfg data. And 3.5 being dropped as a default environment and 3.7 being the only py3 that is run by default.
14:35:48 <abhishekk> I had a strange observation, when you run tox -e functional, it installs dependency under "glance/.tox/functional/lib/python3.5" so does that mean these tests are running against py35 and not py27?
14:35:48 <smcginnis> That requires developers getting py37 installed on their systems, but I think it's a safe target as anything we do in 37 should be fine in 36. At least as long as it still passes py27.
14:35:56 <jokke_> smcginnis: ok, so indeed, defaulting to py37, not py36 like we do now and brian commented on that patch
14:36:17 <smcginnis> Yep, I think he is right.
14:36:42 <jokke_> #agreed we should have our default env py37 instead of py36
14:36:59 <jokke_> great, no we know how to get this moving as well :D
14:37:23 <jokke_> #topic open discussion
14:37:28 <jokke_> Anything else?
14:37:40 <abhishekk> can someone comment on the patch as well?
14:37:46 <jokke_> yes
14:37:50 <abhishekk> I had a strange observation, when you run tox -e functional, it installs dependency under "glance/.tox/functional/lib/python3.5" so does that mean these tests are running against py35 and not py27?
14:39:07 <abhishekk> I found this when I tried to run functional tests of glance by copying glance_store code to tox virtual environment
14:39:15 <jokke_> done
14:39:39 <smcginnis> abhishekk: Oh, yes it does!
14:40:01 <smcginnis> I think that's a side effect of moving to bionic nodes.
14:40:26 <smcginnis> I think we need to add a line under [testenv:functional] of "basepython = python2.7"
14:40:28 <abhishekk> so why we were having functional and functional-py35 two different jobs doing same thing
14:40:42 <jokke_> no, it's side effect of changing the default env to py3 and not declaring the functional running 27
14:40:42 <abhishekk> smcginnis, thanks, I will try adding that
14:41:01 <jokke_> so we indeed run both our functional test sets under py3
14:41:06 <jokke_> good catch abhishekk
14:41:07 <smcginnis> I would be happy to see only one of them (probably the 37 one) defined in the default targets.
14:41:18 <abhishekk> thanks
14:42:14 <jokke_> so we have functional-py3x and functional (later is the 27 job that did not have env declared as we were defaulting 27, which means that they have both ran py3 for at least whole Stain and train so far)
14:42:48 <jokke_> so we need to specify py27 in the functional job in tox.ini
14:42:56 <jokke_> as env
14:44:42 <abhishekk> I also have one question, to use direct snapshot of nova both nova and glance should use same rbd pool?
14:45:14 <jokke_> abhishekk: yes, nova's ephemeral storage needs to be the same rdb as glance image store for that to work
14:45:33 <abhishekk> jokke_, thanks
14:45:51 <jokke_> Anything else?
14:46:39 <abhishekk> Nope, can anyone please report this functional-py35 bug, I am using mobile as traveling back to home from office
14:46:58 <jokke_> Have your 13min back from today. Thanks all!
14:47:07 <abhishekk> thank you all
14:47:09 <jokke_> #endmeeting