14:00:01 <jokke_> #startmeeting glance 14:00:02 <openstack> Meeting started Thu May 3 14:00:01 2018 UTC and is due to finish in 60 minutes. The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 <openstack> The meeting name has been set to 'glance' 14:00:07 <jokke_> #topic roll-call 14:00:16 <rosmaita> wow, that was on time! 14:00:23 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:39 <jokke_> ;) 14:01:01 <rosmaita> hi scott 14:01:03 <McClymontS> o/ 14:01:08 <jokke_> o/ 14:01:14 <rosmaita> o/ 14:01:20 <jokke_> lets give couple of min if others join 14:02:37 <rosmaita> jokke_ : here's why I couldn't use None for the default: https://bugs.launchpad.net/openstack-requirements/+bug/1765748/comments/7 14:02:39 <openstack> Launchpad bug 1765748 in OpenStack Global Requirements "webob-1.8.1 breaks projects" [High,In progress] - Assigned to Matthew Thode (prometheanfire) 14:02:45 <abhishekk> o/ 14:02:52 <jokke_> hi abhishekk 14:03:02 <abhishekk> jokke_, hi 14:03:03 <rosmaita> LMK if i should include that info in the commit message or in a comment in the function 14:03:29 <jokke_> rosmaita: cool ... will have a look after the meeting 14:03:35 <rosmaita> ty 14:03:39 <jokke_> lets kick this circus on the road 14:03:47 <jokke_> #topic updates 14:04:00 <jokke_> Few things has been on flight over past week 14:04:11 <jokke_> first the TC elections finished 14:04:43 <jokke_> #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130052.html 14:04:47 <rosmaita> congrats to sean! 14:05:38 <rosmaita> and here he is! 14:05:41 <abhishekk> Congratulations smcginnis 14:05:43 <McClymontS> lol 14:05:53 <smcginnis> Hah, thanks. 14:05:55 <jokke_> would like to extend our congratulations to all newly elected TC members and folks, these are the people who specially put their names to the hat to be bugged all kind of stuff so utilize them :D 14:06:08 * smcginnis is at a conference and will only be partly here 14:06:27 <jokke_> smcginnis: cool, gz nad welcome 14:06:59 <jokke_> then we had gerrit server upgrade (replacement) that was concluded again 14:07:11 <jokke_> #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130146.html 14:07:43 <jokke_> I don't know that any of us have been affected by these, but just that you know, the gerrit server IPs changed again due to this process 14:08:53 <jokke_> And the Forum schedule is up for summit! 14:09:02 <jokke_> #link https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224 14:09:44 <jokke_> so time to make sure for our attendees to mark these to your calendars, we have few sessions there related to Glance 14:10:55 <McClymontS> Looking forward to seeing/meeting all those who are attending 14:11:39 <jokke_> and last but not least there was mail from dhellmann about the next phase of our PY3 transformation. I think we're in pretty good place for this but I'm still double checking 14:11:44 <jokke_> #link http://lists.openstack.org/pipermail/openstack-dev/2018-April/129866.html 14:11:54 <rosmaita> also 14:11:57 <rosmaita> #link https://etherpad.openstack.org/p/glance-pike-python35-goal 14:12:07 <rosmaita> we are ok with client and store 14:12:11 <smcginnis> Was there one of our repos that we still need to do some work? 14:12:19 <rosmaita> two tests in glance 14:12:19 <jokke_> if anyone has any concerns or do remember us having still tests skipped in py3 lets raise these and get them fixed 14:12:33 <rosmaita> glance/tests/functional/test_reload.py 14:12:46 <rosmaita> glance/tests/functional/test_ssl.py 14:12:53 <rosmaita> i believe that's everything 14:13:01 <smcginnis> rosmaita: Do we have a bug tracking these? 14:13:13 <rosmaita> smcginnis very possibly not 14:13:14 <jokke_> the ssl test was some weirdness how the cert relocation/registration was hadnled, right? 14:13:34 <rosmaita> jokke_ yes, i think maybe we need to either regenerate the static cert we use, or generate on the fly 14:13:40 <rosmaita> but i have not looked closely 14:14:21 <rosmaita> #action rosmaita check for glance py35 functest bug, file one if does not exist 14:14:33 <jokke_> ok, lets try to keep these on medium priority for now and get them sorted. Definitely if we do not have bugs tracking them lets open them and set the bug priority to high 14:14:54 <jokke_> thanks 14:16:26 <jokke_> that's all from me ... we should have good time during open discussion if any questions arise 14:16:36 <jokke_> #topic release updates 14:16:43 <jokke_> rosmaita: stage is yours 14:16:54 <rosmaita> #topic release update 14:17:12 <rosmaita> ok, our community goals are completed and acknowledged in storyboard 14:17:30 <rosmaita> thanks to abhishek for getting rid of mox 14:17:49 <abhishekk> o/ 14:17:50 <rosmaita> and people way back in time who implemented live-reload of glance config 14:18:00 <jokke_> :) 14:18:14 <rosmaita> nothing pressing at the moment release-wise, just some awareness of upcoming deadlines 14:18:32 <rosmaita> next week is R-16 ("R" is for "release", not "rocky) 14:18:46 <rosmaita> the summit is in week R-14 14:18:56 <rosmaita> (the "-" is for "minus") 14:19:11 <rosmaita> and the next big deadlines come in R-12 14:19:14 <jokke_> and our spec freeze was set to R-12 iirc 14:19:16 <rosmaita> that's the rocky-2 milestone 14:19:22 <rosmaita> and also the spec freeze 14:19:25 <rosmaita> as jokke_ just said 14:19:48 <jokke_> :D 14:20:04 <rosmaita> sorry, i had "feature freeze" on the agenda, that was a typo 14:20:14 <rosmaita> that's it from me 14:21:08 <jokke_> as lots of us are in the Summit and I will be on holidays the week following summit (I'll be looking for the spec stuff at least on that week) Lets try to get the specs we have good plan now nailed down 14:21:50 <abhishekk> * kindly review multi-store specs (https://review.openstack.org/#/c/562467) 14:22:05 <jokke_> please folks review the outstanding specs and cast your vote there so I have your ack and I can start merging them, also who has specs which needs work, lets prioritize to get the changes out there 14:23:11 <jokke_> I'm gonna hardline -2 and move to S anything that is not good to go at the freeze 14:23:38 <abhishekk> that reminds me bhagyashris is on vacation this week, most probably she will update us on policy related work 14:23:48 <rosmaita> i have a question about https://review.openstack.org/#/c/561111/ , the deprecate store_capabilities_min_interval spec proposal 14:23:51 <jokke_> abhishekk: ok, thanks for the heads up 14:24:25 <jokke_> rosmaita: ok let me change the topic 14:24:33 <jokke_> #topic Open Discussion 14:24:39 <rosmaita> my question is that i kind of like the alternative i mentioned in the spec 14:24:45 <jokke_> this way it doesn't fall under the updates on the logs 14:24:48 <rosmaita> sure 14:25:31 <rosmaita> my question is whether that's an implementation detail, or whether we need to decide in advance what to do 14:26:03 <rosmaita> i guess it's not an implementation detail, because if we take the alternative, we won't actually deprecate the option 14:26:11 <rosmaita> it will just be clearly marked as a "no-op" 14:26:26 <jokke_> well I personally think that the alternative kind of leaves the door open again to keep the option, which we already did in the last cycle in case someone comes up for real use-case and implementation for it 14:26:48 <jokke_> I think it would be better to just get rid of it and put it back to the planning table if it's actually needed some day 14:27:02 <abhishekk> +1 14:27:38 <rosmaita> ok, sounds good ... jokke_ can you put a note on the review saying def do not want to do the alternative? 14:27:56 <jokke_> rosmaita: sure 14:28:15 <rosmaita> or, you could tell me to remove the alternative 14:28:21 <rosmaita> that might be even more clear 14:28:39 <jokke_> #action jokke to clarify we are removing the 'store_capabilities_update_min_interval' not just marking it as noop 14:28:46 <rosmaita> ty 14:29:22 <rosmaita> ok, while we are all here, question about the wait-for-status function we talked about last week 14:29:30 <rosmaita> https://review.openstack.org/#/c/564649/ 14:29:43 <rosmaita> the question is how to handle default values 14:29:44 <jokke_> ok, you had couple of other highlights in the Open Discussion rosmaita 14:30:04 <jokke_> #link https://review.openstack.org/#/c/564649/ 14:30:16 <rosmaita> maybe there should be no defaults so if you use the function you must explicitly set everything? 14:30:45 <jokke_> So I do like it having sensible defaults _and_ it being clear in the test calling it what values are being used 14:31:27 <jokke_> makes the debugging of those tests much easier in the future and also makes it easier to figure out what kind of values are used when writing new tests using that function 14:31:40 <rosmaita> so that would basically be the patch that's up now 14:31:43 <jokke_> even on the cost having couple of extra lines in our test code 14:32:05 <abhishekk> sounds good then 14:32:32 <rosmaita> ok, cool, we should merge it, we are still seeing the failures in the gate 14:32:41 <jokke_> only thing I put into the review was suggestion should we change the wording interval to delay? As it's not really an interval 14:32:53 <jokke_> but I'm open to discussion on that 14:34:02 <rosmaita> i had thought about that, but decided to say what "interval" meant in the docstring comment 14:34:35 <jokke_> as interval suggests the request being sent every X (default 0.2 sec) which it does not do 14:34:58 <jokke_> yeah it's explained there, was just thought that we have now good opportunity to be clearer on that if we wish :) 14:35:06 <rosmaita> sure, being clear is good 14:35:22 <rosmaita> i didn't want it to be confused with the start_delay_sec 14:35:51 <jokke_> I can see that, but they are really same thing just applied to different stages of the execution 14:36:29 <rosmaita> i can go either way on this ... abhishekk , smcginnis ? 14:36:39 <jokke_> If you guys think the interval is better, I'm fine with that if we decide to change it and are otherwise ok with the change I'll ninja it in once the change has passed the check 14:37:06 <abhishekk> I am fine with the interval 14:37:14 <jokke_> I want this in and fixed ... I have no intentions to postpone it further as long as we're all on the same page 14:37:54 <rosmaita> so to be clear what jokke_ is proposing, it would be s/interval_sec/delay_sec/ 14:38:55 <jokke_> I would like to see that unless you guys feel strong about keeping it as interval 14:39:42 <jokke_> sorry I had not posted my comments 14:39:45 <jokke_> just did so 14:39:48 <rosmaita> i don't have a good argument that 'interval' is better 14:39:54 <jokke_> perhaps makes my comments here clearer 14:40:16 <McClymontS> Interval 14:41:00 <abhishekk> in some tempest I have observed they are using as interval only 14:41:57 <jokke_> abhishekk: but are they using interval as on top of the actual execution time or are they doing actual intervals? 14:42:28 <abhishekk> jokke_, that I have not verified ;) 14:43:14 <rosmaita> well, i think since the current name misled at least one person, it's worth changing 14:43:15 <jokke_> for me 'interval' == 2 sec ... we shoot request every 2 sec regardless if it takes .5 or 5 sec to execute the previous or 'delay' == 2 sec we delay the next request 2 sec after the execution of the previous finishes 14:43:29 <abhishekk> So if we have enough time then spin a new patch with change 14:44:00 <jokke_> it's really just nitpicking 14:44:02 <rosmaita> ok, i will do that right away ... it seemed to take forever to get the first patch to pass the gate, though 14:44:14 <jokke_> and I can live with either as long as we decide and are on the same page :D 14:44:28 <abhishekk> :D 14:44:44 <jokke_> so if you change it I will just +2A as soon as zuul gives green light 14:44:56 <rosmaita> well, maybe let's just merge the current patch, and someone can propose a follow-up 14:45:14 <rosmaita> because once it's merged, we will see fewer failures for the follow up! 14:45:44 <jokke_> well if this still fails, it clearly does not fix the issue it's there to fix 14:45:54 <jokke_> and we need to find out what is the actual issue 14:46:10 <rosmaita> it's the scrubber, i think 14:46:16 <rosmaita> next topic, actually 14:46:23 <jokke_> ok, lets hop on that 14:46:28 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1768077 14:46:30 <openstack> Launchpad bug 1768077 in Glance "intermittent functional test failures related to scrubber" [Undecided,Triaged] 14:46:30 <jokke_> before we run out of time 14:46:33 <rosmaita> this one really sucks 14:46:46 <rosmaita> different failures in py27 and in py35 14:47:07 <rosmaita> not sure what is going on and i am hoping someone else wants to look 14:47:32 <rosmaita> could work with clarkb in infra channel maybe 14:47:43 <rosmaita> he thinks we are closing a file descriptor early 14:47:48 <abhishekk> may be we can ask wangxiyuan to have a look? 14:47:57 <rosmaita> abhishekk ++ 14:48:01 <abhishekk> he has worked a lot on scrubber 14:48:15 <rosmaita> my gut feeling is that the test he added is fooling the test harness 14:48:25 <abhishekk> I will try to catch him during my day time 14:48:46 <rosmaita> he has this loop in there that runs the same test over and over 14:49:08 <jokke_> hmm-m is there possibility that we have encoding differences in the scrubber output? That's just first thing that comes to my mind for possibility causing this kind of issues? 14:49:10 <rosmaita> each time the test raises an assertion error, it is run again 14:49:15 <rosmaita> for like 15 times 14:49:26 <rosmaita> jokke_ could be, i don't know 14:49:41 <rosmaita> and i don't know why we see different errors in py27 vs py35 14:49:45 <abhishekk> i will also have a look 14:50:15 <rosmaita> cool, there are details on the bug 14:50:33 <rosmaita> i put the log output into pastes because i don't know how long zuul will keep them around 14:50:39 <jokke_> 'cause we should not be handling the fd for the scrubber output manually anywhere so it should not be cuased by us. Although if we dump something into that pipe that makes the subunit to barf it might look like it's the pipe that failed 14:50:56 <abhishekk> great 14:51:21 <rosmaita> yes, i did not see anything that was manually messing with the fd for scrubber output 14:51:30 <jokke_> and that would explain why it behaves differently in py27 and py3 14:51:48 <jokke_> as they do handle string encodings differently 14:52:04 <rosmaita> that's a possibility 14:52:46 <rosmaita> also, i think these are hard to reproduce locally, unless you run on a really slow system so the tests have to be retried 14:53:09 <jokke_> I have no evidence it being the case, just gut feeling/sofisticated guess :P 14:55:14 <abhishekk> Last 5 minutes 14:55:52 <abhishekk> jokke_, I will ping you tomorrow morning (your time) for some discussion related to multi-store 14:56:00 <jokke_> ok, so priorities for now: Gating issues including the scrubber test failures and rosmaita's patch for the status check, outstanding specs, the 2 PY3 tests that are skipped 14:56:28 <abhishekk> sounds good 14:56:29 <jokke_> anything else we should be really trying to get off from our plate by the time of Summit? 14:57:10 <abhishekk> any updates on multihash? 14:57:51 <rosmaita> not yet 14:57:59 <McClymontS> Have to talk more w/ rosmaita 14:57:59 <abhishekk> ok 14:58:09 <jokke_> I saw couple of patches from Scott but seems like they still need some work to get through gate 14:58:23 <abhishekk> may be you will have some discussion during summit 14:58:26 <McClymontS> Test failures etc, were going to circle back soon 14:58:50 <jokke_> McClymontS: feel free to tap me in as well if you need help brainstorming 14:59:07 <rosmaita> i really need to get McClymontS some feedback 14:59:10 <McClymontS> Appreciate it jokke_, surely we will catch up on it at the summit as well 14:59:21 <abhishekk> ok, thank you all 14:59:21 <McClymontS> my time for implementation might be limited, but a lot of the framework is right there 14:59:30 <jokke_> McClymontS: yeah ... lets try to get that sorted by milestone 2 14:59:46 <jokke_> ok we're out of time, anything else --> #os-glance 14:59:53 <jokke_> #endmeeting