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