14:02:30 #startmeeting glance 14:02:31 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:34 The meeting name has been set to 'glance' 14:02:38 o/ 14:02:43 o/ 14:04:11 #topic roll call 14:04:12 o/ 14:04:15 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:04:24 o/ 14:04:45 soo short meeting based on the agenda today 14:05:25 #topic release updates 14:06:26 abhishekk: how is our periodic jobs looking, everything still green? 14:06:29 so we had a glance_store release last week, but it is breaking the glance backward compatibility at the moment 14:06:53 jokke_, glance_store periodic tips jobs are failing 14:07:30 ok 14:07:47 jokke_, once we revert this change https://review.opendev.org/#/c/663889/ it will be good to go 14:08:09 #link https://review.opendev.org/#/c/663889/ 14:08:14 or https://review.opendev.org/664865 we need to merge this glance change 14:08:30 #link https://review.opendev.org/#/c/663894/ 14:09:06 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 Do we want the revert, or to fix the tests? I wasn't sure on that. 14:10:45 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 smcginnis: I think you even +W'd it :) 14:12:41 in that case we need revert 14:13:00 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 We can always "unblacklist" if we decide it's actually OK. 14:15:25 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 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 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 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 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 smcginnis: correct 14:18:49 OK, approved the revert and the release note, so phase one should be done. :) 14:18:57 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 smcginnis: great, we can tag the 0.29.1 release today if those merges cleanly 14:19:22 jokke_, yeah, that never touched my mind 14:19:50 then the next thing which is related to that 14:20:44 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 which is one of those patches we need to have ready to go 14:21:50 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 so do we need to have migration for this or I can do it in lazy store loading patch? 14:23:23 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 And mention in the release notes that if one had multi-store enabled the upgrade will take bit of time 14:24:34 the good thing is that it should be very very quick for everyone who haven't gone into multi-store yet 14:24:46 so, I will work on migration script tomorrow 14:24:47 as the migration is effectively noop 14:25:33 smcginnis: so updating the constant and including that line in semver should just pass the test cleanly? 14:25:49 sorry, commit message 14:26:06 without any tags involved 14:26:53 jokke_: I believe so. 14:27:38 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 ack 14:27:56 or I will submit the doc clarification with the patch 14:28:02 cool 14:28:09 that gets us moving forward 14:28:35 If that works it will make the life with migrations so much easier 14:29:03 smcginnis: ^^ that being the case I owe you some beverages when we meet next time :P 14:29:20 jokke_: After I buy you one. :) 14:29:46 * jokke_ can foresee wet night ahead 14:30:02 ok, lets move on if that's all around our releases 14:30:48 #topic default tox environment 14:31:03 Brian put this into the agenda 14:31:23 #link https://review.opendev.org/#/c/664475/1/tox.ini@3 14:31:26 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 so last sentences is advising to remove py34 and py35 environments 14:33:09 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 so we indeed should include the py37 nad I guess default to that as well? 14:34:50 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 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 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 smcginnis: ok, so indeed, defaulting to py37, not py36 like we do now and brian commented on that patch 14:36:17 Yep, I think he is right. 14:36:42 #agreed we should have our default env py37 instead of py36 14:36:59 great, no we know how to get this moving as well :D 14:37:23 #topic open discussion 14:37:28 Anything else? 14:37:40 can someone comment on the patch as well? 14:37:46 yes 14:37:50 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 I found this when I tried to run functional tests of glance by copying glance_store code to tox virtual environment 14:39:15 done 14:39:39 abhishekk: Oh, yes it does! 14:40:01 I think that's a side effect of moving to bionic nodes. 14:40:26 I think we need to add a line under [testenv:functional] of "basepython = python2.7" 14:40:28 so why we were having functional and functional-py35 two different jobs doing same thing 14:40:42 no, it's side effect of changing the default env to py3 and not declaring the functional running 27 14:40:42 smcginnis, thanks, I will try adding that 14:41:01 so we indeed run both our functional test sets under py3 14:41:06 good catch abhishekk 14:41:07 I would be happy to see only one of them (probably the 37 one) defined in the default targets. 14:41:18 thanks 14:42:14 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 so we need to specify py27 in the functional job in tox.ini 14:42:56 as env 14:44:42 I also have one question, to use direct snapshot of nova both nova and glance should use same rbd pool? 14:45:14 abhishekk: yes, nova's ephemeral storage needs to be the same rdb as glance image store for that to work 14:45:33 jokke_, thanks 14:45:51 Anything else? 14:46:39 Nope, can anyone please report this functional-py35 bug, I am using mobile as traveling back to home from office 14:46:58 Have your 13min back from today. Thanks all! 14:47:07 thank you all 14:47:09 #endmeeting