14:00:04 <jokke_> #startmeeting glance
14:00:05 <openstack> Meeting started Thu Mar  7 14:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'glance'
14:00:08 <jokke_> #topic roll-call
14:00:11 <jokke_> o/
14:00:25 <rosmaita> o/
14:00:31 <jokke_> lets try this again :D
14:00:39 <abhishekk> :D
14:00:43 <abhishekk> o/
14:00:54 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:09 <jokke_> #topic updates
14:01:46 <jokke_> #link https://review.openstack.org/#/c/639376/4/goals/train/osc.rst
14:01:58 <jokke_> so someone thought that this was good idea without talking to us
14:02:27 <jokke_> There is again talks about moving to osc and to the Open Stack SDK
14:02:46 <abhishekk> omg
14:02:55 <jokke_> and funny enough glance is specially mentioned priority in that community goal
14:03:10 <abhishekk> :D
14:03:32 <jokke_> fear not, I have no intetion what so ever to stretch us into that
14:04:11 <rosmaita> i didn't realize they don't use the glanceclient, that explains a lot
14:04:45 <rosmaita> like the "properties" image property
14:04:52 <rosmaita> but i digress
14:05:09 <rosmaita> i endorse jokke_ keeping us out of this one
14:05:19 <abhishekk> +1
14:05:20 <jokke_> we have enough to do without. At least my stand is that we keep maintaining python-glanceclient as reference interface to Images API and if someone (Monty) wants to get the SDK and osc (don't know who is driving the glance efforts) on par they can freely do so
14:05:44 <jokke_> and if any of the services decides to go with the SDK they can freely contact Monty if issues arise
14:05:51 <abhishekk> agree
14:06:07 <rosmaita> works for me
14:06:33 <jokke_> cool, just wanted to give you guys heads up that this is yet again on the table
14:06:36 <rosmaita> it would be nice if they at least refer to our reference implementation
14:06:55 <rosmaita> there has been some cowboy stuff going on, particularly around image sharing
14:07:14 <jokke_> I haven't yet put my thoughts into that review. I would have been way too nice and polite if I did so  yesterday
14:09:38 <jokke_> We had discussion about the osc images situation in Berlin and it was made quite clear to me that they have to redo it as it just doesn't work. Which is fine by me and as long as they don't come to us with it, I'm happy to let the osc folks to go their own way on this
14:10:16 <abhishekk> agree
14:10:21 <jokke_> Same time I don't see it being fair to anyone for us to deprecate the python-glanceclient
14:11:07 <jokke_> In my point of view nothing has changed since ~2years ago this was last time on the table
14:11:15 <abhishekk> yes
14:11:28 <jokke_> ok, enough of that rant, lets move on
14:11:40 <jokke_> #topic release updates
14:11:46 <jokke_> big day again today
14:11:56 <abhishekk> yes, glance_store version 0.28.0 released last week
14:12:07 <abhishekk> glance and python-glance client should be released today
14:12:38 <rosmaita> cool
14:12:43 <abhishekk> we have at least 5-6 patches waiting to be get approved
14:12:48 <rosmaita> uncool
14:12:50 <abhishekk> #link https://etherpad.openstack.org/p/glance-stein-milestone-3
14:13:19 <abhishekk> glance has couple of issues related image-import and feature such as cache-management and windows driver
14:13:39 <abhishekk> image visibility might need FFE as tempest patch is not merged yet
14:14:51 <abhishekk> also we need patches for release-notes and config generation,  I have added these in the TODO section of above etherpad
14:14:55 <jokke_> so first of all, we do not need to tag m-3 so lets focus to get the client release out of the door today
14:15:09 <rosmaita> makes sense
14:15:45 <jokke_> #link https://review.openstack.org/#/c/602794/
14:16:24 <jokke_> that's the only feature I know of that is pending approval we would need to not need to backport yet another feature after the "final" client release
14:16:52 <abhishekk> should we submit new PS to remove that white space from the release notes?
14:17:24 <jokke_> tbh it's easy fix on the reno patch
14:17:35 <jokke_> if you guys agree on the implementation itself
14:17:40 <rosmaita> ok, let's do that then
14:17:51 <rosmaita> it's got 2 +2s, so looks ready to go
14:17:55 <abhishekk> I am ok with the patch
14:18:22 <rosmaita> i was hoping the --backend thing could be included, but i have no objection
14:18:55 <jokke_> #link https://review.openstack.org/#/c/602577/
14:19:23 <jokke_> this has not had movement since the last reviews and has 2 -1s on it, so will skip to the next release
14:19:44 <abhishekk> ack
14:20:08 <jokke_> #link https://review.openstack.org/#/c/601225/
14:20:22 <jokke_> I'd like to know what's going on in that one
14:21:21 <jokke_> the commit message is messy, it claims it fixes something that's broken but there is no bug for it. And I did not get any response to my concerns in past couple of days
14:22:29 <jokke_> I think I kind of got the grasp of it and there might be opportunity to fix that, but in this point I'd say not to merge it as it is at least and we can definitely make backport candidate out of that if it is indeed bug
14:22:41 <rosmaita> the author has probably completely forgotten about it
14:22:51 <rosmaita> anyway, i agree with jokke_
14:23:43 <abhishekk> yes, but he probably was talking about this, https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/adapter.py#L230
14:23:50 <jokke_> Do we have anything else I have missed. The test env is not release blocking
14:24:28 <abhishekk> jokke_, we need release-notes patch for that
14:24:43 <jokke_> abhishekk: like siad I likely got it as I think I came to same conclusion. Although I have not played around with it to confirm us indeed having issue there
14:24:46 <jokke_> said
14:25:02 <abhishekk> jokke_, agree
14:25:13 <jokke_> abhishekk: yes we will need reno patch for the client prior to release
14:25:57 <jokke_> so if I haven't missed anything and the verification is go, I'll write the reno patch after the meeting again
14:26:09 <abhishekk> ++
14:26:28 <jokke_> it should be faster merging this time as I think rosmaita added the file ignoring to the test rules here as well
14:26:33 <rosmaita> :)
14:26:52 <abhishekk> :D
14:27:11 <rosmaita> we still need to merge the glance_store change, when anyone has a minute: https://review.openstack.org/640158
14:27:24 <rosmaita> no rush
14:27:42 <jokke_> yeah, good to keep in mind but not client release blocker :D
14:27:47 <rosmaita> yep
14:28:05 <jokke_> So I just wanted to be sure I haven't missed anything for the client release
14:28:14 <jokke_> tried to review everything at the start of the week
14:28:27 <jokke_> so please yell now if we have anything else pending you know of
14:28:43 <abhishekk> nothing from me that I know of
14:29:17 <jokke_> \\o \o/ o// o/7
14:29:41 <jokke_> then we can lift the milestone 3 on to the table and feature freeze
14:30:03 <jokke_> so FF is next week or two weeks from now? Somewhere very close anyways
14:30:49 <abhishekk> FF is in same week as milestone 3
14:30:58 <abhishekk> #link https://releases.openstack.org/stein/schedule.html
14:31:01 <rosmaita> yeah, i think now
14:32:08 <jokke_> woops my bad
14:32:42 <jokke_> ok, what do we have on the table feature wise we have been kicking down the road until now?
14:33:03 <jokke_> The visibility change by looks of it is yet another thing blocked by tempest
14:33:15 <rosmaita> yeah, we need to work that one out
14:33:22 <abhishekk> cache-management using v2, visibility and windows driver
14:33:39 <rosmaita> whatever happened to removing owner_is_tenant ?
14:34:08 <jokke_> so the cache management is something we _need_ to get merged for this release even it has been hanging for long time
14:34:11 <jokke_> sorry abhishekk
14:35:07 <rosmaita> i think the cache management patch was looking good,
14:35:52 <abhishekk> it is (IMO :D)
14:36:28 <jokke_> ok, how about this, we're two weeks from RC1, we're currently hititng on string soft freeze so we need to be careful about that. Lets get the cache management reviewed today
14:36:39 <rosmaita> ok, i can do that
14:37:07 <abhishekk> great
14:37:23 <jokke_> other than that I'm suggesting we focus on any feature review work by next Wed and we hit the panic button on next weeks meeting if we still have some FFEs we need to consider
14:37:27 <jokke_> ?
14:38:06 <jokke_> What I'm saying is, lets give blanket FFE for anything in flight to be reviewed by next Wed.
14:38:09 <abhishekk> works for me
14:38:11 <rosmaita> ok
14:38:38 <jokke_> we've had enough firefighting last couple of weeks that I at least totally missed the fact us hitting FF today
14:39:32 <abhishekk> so I don't need to be online today? (I am down with fever and throat infection for last couple of days)
14:40:07 <rosmaita> abhishekk: you need to get some rest, jokke_ and i can get glanceclient released today
14:40:18 <jokke_> #action everyone review any glance feature work by Wed 13th. If your patch is being missed poke us on #openstack-glance and get attention to it early next week
14:40:27 <jokke_> what rosmaita just said!
14:40:34 <abhishekk> rosmaita, jokke_ thanks
14:40:46 <jokke_> ok, lets move on
14:41:29 <jokke_> ohh quick one before that
14:41:39 <jokke_> abhishekk: how has the periodic jobs been looking?
14:42:01 <abhishekk> jokke_, it looks good now, only one failure in last 3 days
14:42:01 <jokke_> still the same failures or anything new in those 3?
14:42:20 <abhishekk> still subunit parser error only
14:42:32 <jokke_> ok, that's kind of good
14:42:35 <jokke_> thanks
14:43:01 <jokke_> #topic glance-store swift driver PY3 encoding errors
14:43:05 <rosmaita> i wish the openstack fairy would fix the subunit parser problem!
14:43:16 <abhishekk> :D
14:43:26 <rosmaita> ok, thanks to bandini, i was able to reproduce the problem, and this looks like a fix:
14:43:35 <rosmaita> https://review.openstack.org/#/c/620234/4/glance_store/_drivers/swift/store.py
14:44:13 <rosmaita> my question is about the failing verifier test, which is expecting that b'' is going to be handed to the verifier at the end of each chunk
14:44:24 <rosmaita> i can just change the test not to look for that
14:44:29 <rosmaita> *tests
14:44:34 <jokke_> abhishekk: in case you have not been following Brian's findings are here:
14:44:38 <jokke_> #link https://etherpad.openstack.org/p/glance_store-py3-swift-driver-problem
14:44:48 <abhishekk> jokke_, thanks
14:45:14 <rosmaita> or, i can change the patch to pass the empty byte to the hashers and the length computation
14:45:21 <rosmaita> which seems kind of dumb
14:45:26 <jokke_> rosmaita: so we do the zero sized read at the end of each chunk?
14:45:28 <jokke_> daumn
14:45:42 <rosmaita> jokke_: i believe that is what's happening
14:45:58 <rosmaita> but why it only causes that weird unicode thing at large images, i have no idea
14:46:00 <jokke_> rosmaita: yeah it is dumb, but we do lots of dumb shait in/due our testing
14:46:33 <rosmaita> i guess my preference is to go with the patch as is, and change the tests
14:46:45 <abhishekk> agree with rosmaita
14:46:48 <jokke_> fortunately adding no data to the verifier is not horribly resource consuming task if I have understood the code correctly
14:46:49 <rosmaita> but be aware that something could break somewhere sometime
14:47:21 <rosmaita> jokke_: right, and that's what the code has been seeing
14:47:41 <rosmaita> so maybe the minimal change is to pass the b'' along
14:47:58 <rosmaita> what i mean is something like
14:48:24 <jokke_> So when the image is small enough and we know the size we don't do chunking. So likely it is the chunking code that we need to look into at some point and hopefully be able to eliminate those reads from the source
14:48:38 <rosmaita> if i == 0:
14:48:39 <rosmaita> result = b''
14:48:39 <rosmaita> else:
14:48:39 <rosmaita> result = (read from fd)
14:49:16 <rosmaita> well, the "do a read and if it's 0 bytes you are EOF" is a pretty standart pattern
14:49:24 <rosmaita> *standard
14:49:42 <jokke_> it feels very hacky but is likely the right thing to do, specially as we actually return that empty byte as well
14:50:09 <rosmaita> ok, i will put up a new patch and we can continue to think it over
14:50:23 <jokke_> thanks
14:50:26 <rosmaita> also, bandini helped me test teh buffered reader
14:50:34 <rosmaita> and it doesn't appear to work
14:50:37 <jokke_> yeah I saw that conversation
14:50:59 <jokke_> so no-one is just using that so far?
14:51:07 <rosmaita> guess not!
14:51:12 <abhishekk> looks like that
14:51:21 <rosmaita> i will file a bug and we can worry about it later
14:51:43 <jokke_> Can we do the same there or is one of those Tim's finding actually finxing that part?
14:51:53 <jokke_> *findings
14:52:13 <rosmaita> i don't think so, buffferedreader inherits from object, not from cooperativereader
14:52:51 <jokke_> ok, lets keep that in mind and we can tackle that after we have fixed this that actually breaks people.
14:52:51 <rosmaita> to be clear, the bufferedreader problem doesn't hit the unicode object problem
14:53:03 <rosmaita> i think it's something different
14:53:09 <rosmaita> i will put details in a bug report
14:53:12 <jokke_> ok, so it's not the same problem, it's just generally broken?
14:53:18 <jokke_> great, thanks
14:53:23 <rosmaita> yeah
14:53:30 <jokke_> so even more then, lets keep them separate
14:53:54 <rosmaita> although, when it's fixed, maybe it will hit the unicode problem!
14:54:05 <rosmaita> call me Mr. Optimistic
14:54:20 <jokke_> well that's problem then and at least that time we will know where to look at ;)
14:54:29 <abhishekk> :D
14:54:35 <jokke_> this was pain to debug
14:54:48 <rosmaita> yes indeed, many thanks to bandini
14:54:50 <jokke_> same time kind of fun. Brought back old memories :D
14:55:19 <jokke_> anything else about this?
14:55:24 <abhishekk> 5 minutes left
14:55:24 <rosmaita> nope
14:55:33 <jokke_> #topic open discussion
14:55:40 <jokke_> Anything else in general?
14:55:46 <rosmaita> yeah, https://review.openstack.org/#/c/637985/1
14:56:03 <rosmaita> please look at my comment and let me know if you want me to lift the -W
14:56:34 <rosmaita> i don't know if it's a big deal or not
14:56:58 <abhishekk> I have seen your comment, doesn't seems to be big worry though
14:58:14 <jokke_> rosmaita: no, I think I can stand behind your assesment and drop my +2 from that
14:58:31 <rosmaita> so do we just want to require a doc change also?
14:58:39 <rosmaita> or a release note?
14:59:12 <jokke_> I'm not sure how big deal that is as user experience, my biggest thing about the +2 was that it wasn't breaking anything but it helped deployment tools that might have ran that generation for some audits
14:59:44 <jokke_> like just blanket run them and if we don't support it those would need to have special rule for us
14:59:55 <rosmaita> in that case, since it's going to return whatever policy file is configured, should be ok
15:00:11 <jokke_> that was my initial thought about it
15:00:43 <abhishekk> time is up
15:00:46 <jokke_> Lets add the note to the ReNo that it's not applicable ruleset without the policy file deployed?
15:00:51 <jokke_> yeah
15:01:12 <jokke_> that's ok for the record before I close? ^^
15:01:18 <rosmaita> works for me
15:01:32 <jokke_> kk, thanks guys!
15:01:36 <jokke_> #endmeeting