14:00:25 <nikhil_k> #startmeeting glance
14:00:25 <openstack> Meeting started Thu Sep  3 14:00:25 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <ativelkov> o/
14:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:29 <openstack> The meeting name has been set to 'glance'
14:00:35 <jecarey> o/
14:00:36 <rosmaita> o/
14:00:44 <nikhil_k> #topic agenda
14:00:49 <nikhil_k> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:51 <flaper87> o/
14:00:57 <bpoulos> o/
14:01:09 <sigmavirus24> hi there
14:01:42 <nikhil_k> Welcome everyone
14:01:44 <nikhil_k> #topic Updates
14:02:11 <nikhil_k> ativelkov had some updates on the artifacts this week.
14:02:12 <abhishekk> o/
14:02:24 <mfedosin> o/
14:03:16 <ativelkov> We still have a number of patches on review
14:03:19 <bunting> o/
14:03:21 <nikhil_k> #link http://eavesdrop.openstack.org/meetings/glance_artifacts_sub_team/2015/glance_artifacts_sub_team.2015-08-31-14.04.html
14:03:29 <ativelkov> #link http://etherpad.openstack.org/p/fastTrackPatches
14:03:30 <mfedosin> there are many fasttrack commits on review
14:03:35 <nikhil_k> The gist is that we do not have blockers for liberty-3
14:03:39 <mfedosin> exactly
14:04:07 <nikhil_k> and client work is currently independent of py-glanceclient
14:04:48 <ativelkov> Yup, the copying of v3 client into murano for release is done in https://review.openstack.org/#/c/219811/
14:05:27 <nikhil_k> We also discussed the necessity of a separate BP that describes the EXPERIMENTAL API work done in Liberty; something independent of API_WG recommendations and good for awareness and documentation
14:05:33 <jokke_> uo/
14:05:45 <nikhil_k> It shall add awareness to the v3 API as well.
14:06:07 <nikhil_k> That was done later, after the meeting.
14:06:31 <mfedosin> I made a bp yesterday
14:07:07 <mfedosin> https://blueprints.launchpad.net/glance/+spec/artifacts-repository-api
14:07:11 <nikhil_k> Thanks mfedosin ! Please share a link whevener convenient
14:07:34 <nikhil_k> great
14:07:34 <mfedosin> We should add all the links there too
14:07:55 <nikhil_k> Anything else?
14:08:13 <mfedosin> nothing from my side
14:08:37 <nikhil_k> For drivers' meeting:
14:08:41 <nikhil_k> #link http://eavesdrop.openstack.org/meetings/glance_drivers/2015/glance_drivers.2015-09-01-14.00.html
14:09:41 <nikhil_k> We discussed liberty-3 reviews and then moved on to a discussiong regarding the need of specs for certain code proposals that do not fit as bugs
14:10:30 <nikhil_k> That's been proposed under discussion topics today
14:11:12 <nikhil_k> #info Liberty-3 is cut today, most likely right after the meeting.
14:11:31 <nikhil_k> We move into the RC and testing phase and the feature freeze begins.
14:12:09 <nikhil_k> For any features that wish to go in Liberty, now is the time to propose and we will need a email to ML as a follow up.
14:12:30 <jokke_> nikhil_k: does the FF start from the cut of l3 or from the cut of RC1?
14:12:31 <nikhil_k> That's feature freeze exception (FFE)
14:12:55 <jokke_> ah k
14:12:58 <sigmavirus24> jokke_: https://wiki.openstack.org/wiki/Liberty_Release_Schedule
14:13:05 <sigmavirus24> jokke_: feature freeze starts when l3 is cut
14:13:10 <nikhil_k> jokke_: it starts now. as any FFE proposals need to come around l-3 cut
14:13:20 <mclaren> there's a small change, if a swift client goes out that https://review.openstack.org/#/c/170564/ might be doable
14:13:26 <mclaren> change->chance
14:13:50 <nikhil_k> mclaren: glance_store 0.9.0 is released today-ish
14:14:07 <jokke_> was released about 30min ago
14:14:20 <wokuma> nikhil_k: by features do you mean bug fixes that address blueprints?
14:14:47 <wokuma> nikhil_k: or does any bug fix count?
14:14:51 <nikhil_k> wokuma: yes, big changes that can have larger impact
14:15:02 <nikhil_k> wokuma: bugs are allowed in RC
14:15:24 <wokuma> nikhil_k: ok thx
14:15:27 <nikhil_k> mclaren: we can do this after RCs before M as well. glance_store doesn't need to wait for M to open
14:16:04 <nikhil_k> mclaren: and we are planning to discuss such things in the next drivers meeting. this will speeden up specs for client and store
14:16:06 <mclaren> nikhil_k: ok, let's see. I think it's probably a very small change to glance in the end -- most of the work was elsewhere
14:18:14 <nikhil_k> Moving on to next topic
14:18:27 <nikhil_k> #topic Feature suggestions as bugs?
14:18:53 <nikhil_k> jokke_,  I suppose it ^ was you?
14:19:11 * sigmavirus24 listens intently to jokke_
14:19:43 <jokke_> I've noticed this over reviews climbing up through the summer
14:20:14 <jokke_> more and more features "This would be nice" being logged as bugs rather than specs or reviews without either
14:20:43 <jokke_> gives me impression that we let perhaps our review guard down as soon as there is bug number in the commit message
14:21:34 <jokke_> is it just me or anyone else noticing that?
14:21:38 <sigmavirus24> jokke_: there are definitely two ways to improve this
14:21:45 <nikhil_k> So is this a pointer to core reviews to become more strict on the review scheme?
14:21:48 <sigmavirus24> Honestly I've not been very with it this cycle because of $WORK
14:22:21 <sigmavirus24> nikhil_k: I think we need two approaches to this: reviewers need to look at bugs before reviewing a patch and we need good triage efforts to eliminate those and mark associated reviews as rejected as well
14:22:43 <jokke_> SimonChung1: I've had lots out of upstream on my plate as well so that's why I'm asking ... have I just hit all of them or is this growing trend?
14:22:52 <flaper87> As I mentioned in the drivers meeting, I believe reviewers should be more careful/strict and whenever a case like the ones mentioned by jokke_ show up, the contributor should be pointed to the right workflow
14:23:15 <flaper87> Guidance is important in this process as I believe people propose those patches in good faith
14:23:25 <mclaren> what are we saying? any minor tweak that isn't strictly a bug needs a spec?
14:23:34 <jokke_> wupf that above there was for sigmavirus24 not SimonChung1
14:23:39 <flaper87> mclaren: I don't think so
14:23:55 <nikhil_k> sigmavirus24: so, you suggestion for scheduled bug day when we do such dedicated efforts of triage?
14:24:04 <jokke_> mclaren: I don't think so, but they should not be masked as bug either
14:24:08 <flaper87> the other thing that was mentioned in the drivers meeting this week was to have a "minor changes" kind of spec that we can triage quicker than normal specs
14:24:18 <sigmavirus24> nikhil_k: that wouldn't hurt at all. We can just do it in #openstack-glance or we can do it in a meeting slot too.
14:24:21 <nikhil_k> mclaren: I think it has to do with the impact of the change, even if it's a tweak.
14:24:42 <mclaren> what about an 'in commit message' spec
14:24:59 <mclaren> for example, take this change: https://review.openstack.org/#/c/218864
14:25:05 <sigmavirus24> mclaren: I think we need to be careful of thousands of "tweaks" that can constitute a larger picture break in behaviour as a means of introducing a feature sans a spec
14:25:18 <nikhil_k> the alternative proposed above ^ . jokke_ had suggested lite-specs
14:25:20 <flaper87> To be entirely honest, I believe these things should be analyzed in a case-by-case basis and when in doubt they should just be brought up to the attention of glance-drivers
14:25:32 <nikhil_k> I wanted to see separation for client and store ones.
14:25:48 <rosmaita> let's look at the link stuart posted, it's a good basis to discuss this
14:25:51 <nikhil_k> and document things that can overlap and affect other specs/functionalities/bugs
14:26:35 <flaper87> #info there are currently some issues w/ gate-glanceclient-dsvm-functional, recheck won't help
14:26:39 <nikhil_k> flaper87: I guess the problem is that we don't have good patrol on the reviews. Some reviewers catch such things and some don't.
14:27:02 <flaper87> nikhil_k: that is entirely true. I think reviewers should be strictier
14:27:07 <mclaren> I agree there is a gap here. Something other than full specs every time sounds like a good idea.
14:27:09 <sigmavirus24> So I haven't reviewed the code but based on the commit message I'm a bit torn. For one this isn't breaking backwards compatibility but it is a feature being snuck in as a bug and that seems ... sneaky
14:27:30 <sigmavirus24> Could a "spec-lite" be a thorough discussion on the ML?
14:27:33 <mclaren> the bug is a wishlist bug
14:27:44 <mclaren> (I think)
14:27:47 <flaper87> mclaren: it is
14:27:53 <sigmavirus24> mclaren: wishlist for OpenStack isn't what launchpad describes it as iirc
14:28:11 <flaper87> sigmavirus24: right but the point is, it wasn't just masked as a bug.
14:28:13 <sigmavirus24> Wishlist is "This is a bug that isn't very severe and would be nice to have a fix for, but it probably isn't really necessary"
14:28:15 <nikhil_k> sigmavirus24: it could, but it isn't discoverable using the metadata gerrit uses
14:28:20 <mclaren> in this case the change is fairly self-explanitory. What exactly are we trying to prevent (genuine question)?
14:28:25 <flaper87> It was marked as a whislist because there's no good way to propose small features like that
14:28:33 <flaper87> and spec-lite sounds like a great idea
14:28:45 <sigmavirus24> flaper87: one could argue it was triaged incorrectly though because there really isn't a bug about it
14:28:51 <sigmavirus24> the commands worked just fine before
14:29:04 <sigmavirus24> yes they were visually not appealing, but they follow the style of other commands in glanceclient
14:29:21 <mclaren> so, "wishlist"
14:29:45 <flaper87> sigmavirus24: right but, originally, whislist were actually used in OpenStack. That's probably were your confusion is
14:30:06 <flaper87> s/were/where/
14:30:17 <flaper87> anyway, I think a good solution would be to have spec-lite
14:30:18 <mclaren> Is anyone advocating a spec for this change?
14:30:50 <rosmaita> a spec seems too heavy-duty
14:30:56 <flaper87> rosmaita: I agree
14:31:10 <flaper87> and it'll have None everywhere
14:31:16 <flaper87> except on the problem description
14:31:16 <mclaren> but some folks aren't happy with bugs either -- so it sounds like we need a middle way?
14:31:30 <flaper87> and in the patch fits in the "Proposed Solution" section :P
14:31:39 <mclaren> heh
14:31:51 <nikhil_k> For one thing, this https://review.openstack.org/#/c/219802/  isn't explaning the need for the back compat
14:32:15 <flaper87> mclaren: on tuesday, we kinda mentioned having a 'one-line spec' kind of process for these things
14:32:25 <flaper87> (please, someone, correct me if I'm wrong)
14:32:30 <nikhil_k> We need to respect the v2 API of Glance API first and then determine what we can back compat
14:32:41 <mclaren> nikhil_k: ok, but that's covered by the openstack 'commit guidelines'?
14:32:42 <jokke_> I'm with sigmavirus24 there ... as it's know not to be a bug in first place, why it's logged as bug?
14:33:26 <flaper87> jokke_: again, assuming good faith, it was openned as a way to track incompatibilities between the various versions in a moment of rush
14:33:47 <flaper87> mclaren: ^ correct me
14:33:48 <mclaren> jokke_: which change are you referring to?
14:33:59 <jokke_> mclaren: that wishlist discussed above
14:34:10 <jokke_> I was just slow wording my thought
14:34:10 <flaper87> So, I agree it is not a bug but there's no other way to report that w/ writing a full spec
14:34:13 <nikhil_k> flaper87: the proposal had one of those ideas and I would say that was where we were going towards. But we really need some metadata on the spec-lite else vital info is bound to get lost. Something 3-10 line specs that have mandatory and optional fields that describe the impact.
14:34:41 <flaper87> nikhil_k: yes yes! I exxagerated with the one-line thing :P
14:34:50 <nikhil_k> :)
14:35:07 <flaper87> anyway, can we move on? we've 30 mins left
14:35:11 <flaper87> actually, 27
14:35:16 <flaper87> and this will require more iterations
14:35:21 <flaper87> and we don't have a solution
14:35:25 <flaper87> nor we'll find one now
14:35:26 <nikhil_k> mclaren: I think syntax of the commit is okay but not necessarily the comprehensiveness
14:35:56 <mclaren> nikhil_k: I agree it doesn't meet the openstack commit guidelines (sorry, don't have the link)
14:36:15 <nikhil_k> http://docs.openstack.org/infra/manual/developers.html
14:37:16 <nikhil_k> In the interest of time, we need to move on. I think we can discuss this in the drivers' meeting or the next one when people have more examples and have thought about it more.
14:37:24 <mclaren> nikhil_k: 3-10 lines would fit in a commit message, and may mean less review overhead (FWIW)
14:38:14 <nikhil_k> But comparison of two or more features isn't viable from that single commit!?
14:38:15 <jokke_> mclaren: ++ and I think we have plenty of room to improve our commit messages
14:38:27 <jokke_> at least I do
14:38:52 <mclaren> nikhil_k: how do you mean? (sorry)
14:39:07 <nikhil_k> mclaren: can we continue on -glance ? This might take time..
14:39:12 <mclaren> sure, np
14:39:19 <nikhil_k> To the next one then..
14:39:25 <nikhil_k> #topic     FFE for 'Single disk image OVA import'
14:39:41 <nikhil_k> rosmaita had some really good notes on it.
14:39:53 <nikhil_k> https://review.openstack.org/#/c/194868/
14:39:58 <nikhil_k> https://review.openstack.org/#/c/214810/
14:40:24 <rosmaita> spec hasn't been updated yet, Kent is supposed to update today, though
14:41:27 <nikhil_k> So, I am proposing meeting on #openstack-glance for a quick sync up tomorrow (Friday, Sept 4) at 1500 UTC
14:41:41 <rosmaita> +1
14:41:47 <jokke_> nikhil_k: can we do it 1400?
14:41:57 <nikhil_k> malini is on the west coast time so, this seems like a good middle ground
14:42:00 <nikhil_k> jokke_: ^
14:42:10 * mclaren can't make it
14:42:14 <rosmaita> 14:30?
14:42:21 <jokke_> I'm most probably not gonna be there either
14:42:26 * flaper87 will try
14:42:27 <jokke_> 14:30 would be fine for me
14:42:35 <rosmaita> mclaren: 14:30?
14:42:45 <mclaren> tomorrow's not good, sorry
14:43:00 <nikhil_k> can we page(r) you? :P
14:43:04 <flaper87> LOL
14:43:15 <nikhil_k> jk :-)
14:43:15 <rosmaita> mclaren: do you have a strong POV on the FFE for this?
14:43:23 <mclaren> not really tbh
14:43:37 <nikhil_k> ok, thanks!
14:43:52 <nikhil_k> I will let people know about 14:30 UTC sync up.
14:44:20 <jokke_> thanks nikhil_k Irish Police does not appreciate IRCing while driving :P
14:44:23 <mclaren> looks failry low risk
14:44:24 <flaper87> nikhil_k: courtesy ping appreciated
14:44:25 <mclaren> fairly
14:44:30 <nikhil_k> surely
14:44:33 <flaper87> thanks
14:44:44 <nikhil_k> Moving on to the releases, etc.
14:44:54 <nikhil_k> #topic Reviews, Bugs and Releases
14:45:00 <nikhil_k> #info python-glanceclient 1.0.0 Released
14:45:16 <nikhil_k> https://pypi.python.org/pypi/python-glanceclient/1.0.0
14:45:22 <nikhil_k> jokke_: anything more?
14:45:54 <jokke_> minor hickups and few questions around --is-public ... other than that way less breaking world that we were afraid of
14:46:22 <mclaren> only ~50% of our command set...
14:47:00 <nikhil_k> It's a default API change!!
14:47:20 <mclaren> how do we compare to other projects which have done that?
14:47:30 <nikhil_k> may be we should have released it 99.0.0
14:47:41 <jokke_> :P
14:47:45 <bunting> Did we skip discussion point 2?
14:47:54 <nikhil_k> following pip
14:48:03 <mclaren> anyway, are folks behind trying to close some of the gaps?
14:48:41 <nikhil_k> bunting: oops, sorry. I thought we covered some during the bugs vs features. Will try to give some time for it
14:48:43 <flaper87> If ppl have some spare time, please help going through the bugs 1.0.0-potencial and propose fixes
14:48:56 <flaper87> Some of those are actual bugs that we can fix
14:49:04 <flaper87> (easily)
14:49:12 <flaper87> some are actually broken :P
14:49:35 <jokke_> flaper87: ++
14:49:38 <flaper87> that said, I'm expecting more panic in the upcoming weeks
14:49:51 <mclaren> are folks behind these kind of changes to increase compatability? https://review.openstack.org/#/c/219802
14:49:57 <flaper87> I don't think enough ppl have pushed the "update" button yet
14:50:08 <jokke_> I'd be happy to request glanceclient 1.0.1 within next week or so if we get fixes coming in
14:50:14 <mclaren> yes please!
14:50:17 <flaper87> jokke_: that's my hope
14:50:30 <flaper87> I htink we should do that to avoid backports
14:50:42 <flaper87> most of these bugs are backportable
14:50:49 <flaper87> but we have enough time to avoid it
14:50:50 <mclaren> a shout out to flaper87 who's been on a bugfix rampage!
14:51:12 * flaper87 blushes and hides behind his mom
14:51:32 <flaper87> if only the gate would work
14:51:39 <jokke_> ++ ... anything we can fix and release before RC1 would be great ... that menas we can cut stable/liberty from that 1.0.1
14:52:01 <mclaren> I'm out of office for a couple days if folks are wondering why I'm not pitching in in the very short term
14:52:07 <flaper87> jokke_: there are patches up already, reviews would be awesome
14:52:18 <flaper87> everyone ^
14:52:23 <mclaren> jokke_: when's that deadline do you know?
14:52:26 <nikhil_k> cool, thanks for awareness
14:52:30 <jokke_> same with glance_store ... keep 'em coming ... was released an hour ago
14:52:35 <flaper87> just go through the 1.0.0-potential bugs and review the ones with a fix proposed
14:52:38 <flaper87> that are not whislist
14:52:40 <flaper87> :P
14:52:40 <jokke_> 0.9.0 was released
14:52:42 <nikhil_k> #info glance_store 0.9.0 Released
14:52:46 <nikhil_k> https://pypi.python.org/pypi/glance_store/0.9.0
14:52:53 <mclaren> so we can get https://review.openstack.org/#/c/219802 into rc1 potentially for example?
14:53:19 <nikhil_k> it's client
14:53:25 <nikhil_k> and they have different release pattern
14:53:33 <flaper87> nikhil_k: yeah he meant in 1.0.1 before rc1
14:53:45 <mclaren> ok, I guess I mean m/stable client
14:53:50 <flaper87> (re a patch release before liberty is out)
14:54:03 <jokke_> so same applies ... that's our current baseline for moving to stable, but we can release patch release before cutting the stable branch
14:54:36 <nikhil_k> I think making back compat changes needs more discussion on operators ML
14:54:39 <jokke_> so no new functionality consider both FF bugfixes just won't be need to be backported if we merge and tag before cutting the branch
14:55:00 <nikhil_k> it would really bad experience if client behaves differently than the API
14:55:11 <jokke_> nikhil_k: ++
14:55:35 <mclaren> nikhil_k: back compat changes? or backwards incompatible?
14:56:07 <nikhil_k> mclaren: example https://review.openstack.org/#/c/219802/
14:56:16 <nikhil_k> and def-core/sdf et.al will come back at us even for this
14:56:23 <nikhil_k> sdk*
14:56:31 <mclaren> nikhil_k: ok I am lost here
14:56:46 <nikhil_k> sure, let's chat offline
14:57:00 <jokke_> nikhil_k: sorry to interrupt, but there is 2 reviews in agenda and we have 3.5min
14:57:00 <mclaren> we can break things with no mail to the list, but if we want to help users by unbreaking things we do?
14:58:00 <nikhil_k> Those reviews were added quite late
14:58:19 <nikhil_k> #open discussion
14:58:25 <nikhil_k> #topic open discussion
14:58:27 <nikhil_k> so, if anyone wants to point out anything
14:58:59 <wokuma> https://review.openstack.org/#/c/195820/ has db2 fixes added.
14:59:14 <nikhil_k> bunting: you have something?
14:59:15 <wokuma> Please review (again). Sorry
14:59:34 <bunting> Yeah, i was going to talk about the backwards compatability
14:59:57 <bunting> because if are backwards compatable at least in the short term, we avoid breaking things
15:00:09 <nikhil_k> hmm
15:00:19 <bunting> Thats why i pushed up that patch to reduce the short-term damage of defaulting to v2
15:00:26 <nikhil_k> This is relative matter to affeting a lot of people
15:00:52 <nikhil_k> bunting: please feel free to continue on -glance
15:00:54 <nikhil_k> I will be there
15:00:57 <bunting> ok
15:00:59 <nikhil_k> we are out of time
15:01:03 <nikhil_k> Thanks all!
15:01:06 <nikhil_k> #endmeeting