14:02:18 <nikhil_k> #startmeeting glance
14:02:19 <openstack> Meeting started Thu Jul 16 14:02:18 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:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:22 <openstack> The meeting name has been set to 'glance'
14:02:26 <kragniz> o/
14:02:27 <rosmaita> o/
14:02:29 <bpoulos> o/
14:02:39 <bunting> o/
14:02:51 <nikhil_k> #info Agenda: https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:03:15 <sigmavirus24> o/
14:03:18 <ativelkov> o/
14:03:45 <nikhil_k> #topic Updates
14:04:04 <nikhil_k> #info Mid-cycles
14:04:13 <nikhil_k> #info Glance mid-cycle: https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup
14:04:46 <nikhil_k> #info Other mid-cycles: https://wiki.openstack.org/wiki/Sprints
14:05:25 <nikhil_k> Nova and Horizon are next week, those who plan to attend (or virtually attend)
14:05:38 <nikhil_k> #info Artifacts Sub-team meeting updates
14:05:48 <Olena> o/
14:06:03 <ativelkov> oslo.version_objects commits on review
14:06:21 <mfedosin> client's too
14:06:25 <ativelkov> https://review.openstack.org/196041, https://review.openstack.org/196819
14:06:44 <ativelkov> commit adopting o.vo in glance - as well: https://review.openstack.org/198798
14:07:25 <mfedosin> jokke_, you said about experimental branch for the client
14:07:30 <ativelkov> created a doc on V3 open issues: https://etherpad.openstack.org/p/glance-v3-open-issues
14:07:36 <mfedosin> can you do that?
14:07:39 <ativelkov> (still in progress of populating)
14:08:13 <nikhil_k> jokke_: will you or will someone from rel-mgrs will be able to create the feature branch?
14:08:19 <ativelkov> There is a good suggestion on refactong V3 code so it's images plugin may run kind-of-on-top-of Images v2 api, thus reusing the existing code
14:08:47 <nikhil_k> ++
14:08:48 <ativelkov> I'll summarize that suggestion in a separate message to the ML
14:08:55 <jokke_> I think it just needs to be proposed to the projects where our branches are defined ... I'll figure it out
14:09:07 <nikhil_k> thanks jokke_
14:09:31 <nikhil_k> sounds like a plan, ativelkov
14:09:37 <mfedosin> jokke_, thanks
14:09:52 <nikhil_k> #info Drivers' team meeting updates
14:09:53 <jokke_> #action jokke_ propose feature branch for python-glanceclient artifacts work
14:10:01 <jokke_> ouch sorry ;)
14:10:14 <nikhil_k> jokke_: sorry :)
14:10:28 <nikhil_k> This week we prioritized the specs
14:10:54 <nikhil_k> A few of them look good and I was waiting to see if someone wants to give last minute feedback after today's meeting
14:11:03 <nikhil_k> else we will merge them today
14:11:21 <jokke_> whoaa :)
14:11:50 <mclaren> nikhil_k: which specs do you hope to merge?
14:11:57 <nikhil_k> #link http://eavesdrop.openstack.org/meetings/glance_drivers/2015/glance_drivers.2015-07-14-14.01.html
14:12:07 <nikhil_k> mclaren: point # c
14:12:31 <mclaren> k, thanks
14:13:27 <malini> good morning!
14:13:28 <nikhil_k> And this one has code ready and almost agreed upon. The lastest changes from wayne can help it merge #link https://review.openstack.org/#/c/179674/
14:15:01 <nikhil_k> I hope no one expects a pre-midcycle virtual meetup this time
14:15:40 <nikhil_k> This one is over 3 days so we can plan to schedule sessions to include people from various timezones over video conferencing
14:15:46 <jokke_> can we open parallel bug with that spec, stating that glanclient does not support the tag metadefs? :P
14:16:09 <nikhil_k> For the rest of the day, we will host whiteboardig and informal discussions (face to face time, basically)
14:16:40 <jokke_> preferably high priority
14:16:58 <jokke_> so we cab backport that to kilo glanceclient
14:17:06 <jokke_> /cab/can/
14:17:07 <nikhil_k> jokke_: Please feel free to and ask it to be added/amended to the spec. It makes sense
14:17:17 <nikhil_k> umm, that I doubt
14:17:51 <jokke_> I know, I wish it was that easy :(
14:18:06 <nikhil_k> :/
14:18:25 <nikhil_k> Moving on
14:18:41 <nikhil_k> #topic Should all API changes require a spec ?
14:18:56 <nikhil_k> Who proposed that?
14:19:08 <jokke_> looks like it was me
14:19:09 <sigmavirus24> Not me, but that kind of grooves with the three reviews I added to today's agenda
14:19:19 <jokke_> but we have been talking about this a bit around
14:19:56 <mfedosin> too many specs spoil the broth :)
14:20:17 <jokke_> so if we streamline our specs process that would aid the documentation and release work when we have clear indication that we have merged something that has changed our APIs
14:20:50 <bunting> As someone now to glance, more specs would help very much, when trying to understand what is going on.
14:21:34 <jokke_> I think that should be very much lite version of spec
14:22:16 <bunting> Yeah, a even a lite version would make understanding come much quicker
14:22:18 <jokke_> and relating to that juis FYI how much I love specs I proposed talk to Tokyo summit with topic "Specs - Taking agility out of agile development" ;)
14:22:27 <nikhil_k> It may soon become a must have very soon the way I see it
14:22:40 * nikhil_k back after irc conn timed out
14:23:30 <nikhil_k> can we add release cycles to that agility discussion?
14:23:55 <jokke_> nikhil_k: the deadline was last night ;)
14:24:07 <nikhil_k> pun intented (irc can be hard)
14:25:03 <nikhil_k> API is gettig a very close attention from those who are pushing the interop capacities to OpenStack APIs
14:25:24 <nikhil_k> Having specs is only going to help
14:25:59 <sigmavirus24> Agreed
14:26:10 <jokke_> yep ... I think changing the v2 api probably becomes next to impossible after nova starts consuming it
14:26:11 <sigmavirus24> There are legitimate bugs in the behaviour of our API that we now can't fix because we're afraid of backwards incompatibility
14:26:12 <sigmavirus24> so
14:26:23 <nikhil_k> Anyways, I had a very interesting discussion with John Garbutt on this topic yesterday. The way Nova specs is evolving seems to make sense from that(Nova) perspective.
14:26:25 <sigmavirus24> we need specs, or we need v3 tomorrow =P
14:26:37 <sigmavirus24> nikhil_k: can you link to how they're evolving?
14:27:06 <jokke_> so can we agree lite spec required for API changes regardless if it is "bug" fix or not?
14:27:17 <nikhil_k> #info Nova specs evolution: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
14:27:31 <malini> Lite specs works! Hate to interrupt, but our lite spec, discussed back in Vancouver is starving for some review: https://review.openstack.org/#/c/194868/
14:28:02 <nikhil_k> #startvote do we require lite spec for API changes regardless if it is "bug" fix or not ?
14:28:03 <openstack> Begin voting on: do we require lite spec for API changes regardless if it is "bug" fix or not ? Valid vote options are Yes, No.
14:28:04 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
14:28:12 <jokke_> #vote yes
14:28:25 <rosmaita> #vote yes
14:28:29 <lakshmiS> #vote yes
14:28:33 <stevelle_> #vote yes
14:28:48 <hemanthm> #vote yes
14:28:52 <nikhil_k> #vote yes
14:28:58 <mclaren> what is a lite spec?
14:29:04 <wayne__> #vote no
14:29:43 <kragniz> specs make the most sense for API changes, but we'd need to make sure these specs actually move forward
14:29:44 <nikhil_k> #action nikhil_k : define `light spec` in specs evolution documentation
14:29:44 <mfedosin> #vote no
14:29:44 <hemanthm> jokke_: do you have a spec up for proposing lite specs? :)
14:29:50 <ativelkov> #vote yes
14:29:53 <jokke_> mclaren: I was planning to propose a template for it if we pass the vote ;)
14:30:01 <jokke_> hemanthm: almost
14:30:19 <malini> #vote yes
14:30:21 <kragniz> why not make our speed of dealing with specs faster before we start mandating them for every api change?
14:30:23 <bpoulos> #vote yes
14:30:52 <mfedosin> do we need ApiImpact flag then?
14:30:58 <wayne__> kragniz: +1
14:31:01 <nikhil_k> #endvote
14:31:03 <openstack> Voted on "do we require lite spec for API changes regardless if it is "bug" fix or not ?" Results are
14:31:16 <sigmavirus24> mfedosin: we do have an ApiImpact flag
14:31:39 <nikhil_k> That's for the API WG and related parties
14:31:50 <malini> mfedosin +1 on APIimpact flag, docimpact
14:32:00 <sigmavirus24> Doesn't mean we can't also use it. Plus having their attention isn't going to hurt
14:32:13 <mfedosin> sigmavirus24, maybe just link for 'lite' spec is enough?
14:32:14 <nikhil_k> Spec would be for everyone to keep track of the API changes and why/how
14:32:15 <sigmavirus24> Unless we don't want their attention at all in which case, why do we keep asking for it?
14:32:33 <jokke_> looks like openstack does not know how to count. Yes: 9 No: 2
14:32:49 <johnthetubaguy> nikhil_k: yeah, was good to chat, can I help with any context?
14:32:58 <nikhil_k> Thanks for the gist jokke_
14:33:23 <johnthetubaguy> FWIW, Neutron is trying out a lite spec kind of thing, it might being a process worth copying?
14:33:26 <mfedosin> I want to explain my concern. This patch changes api https://review.openstack.org/#/c/200980/
14:33:37 <mfedosin> do we need a spec for it?
14:33:58 <nikhil_k> johnthetubaguy: Thanks for the feedback. We are just have a small discussion on when do specs make most sense. Please feel to chime in :)
14:34:55 <johnthetubaguy> so I think that question is best answered after you get the code merged, and I am not totally joking...
14:35:26 <jokke_> mfedosin: I'm happy to revert that change if it really changes the behavior of our v1 Images API (which IMHO it does not)
14:35:54 <nikhil_k> mfedosin: that's a good pointer. I think we need to see if this is being validated at the API level. We can't make a change to v1 at this point
14:36:05 <johnthetubaguy> when you have a decision you need to record, mostly to make sure everyone is on the same page, specs work really well, when you need to just see the code to answer a question, you don't want a spec to make that decision
14:36:07 <jokke_> mfedosin: difference being does it change our api code or does it change our public api
14:36:07 <mfedosin> jokke_, it does (see my comment), but very slightly
14:36:19 <lakshmiS> i think spec will make the commiter think about all the things covered in the template  specifically for api related changes and also act as document initially
14:37:01 <jokke_> mfedosin: Jenkins agrees, did not merge ;)
14:37:06 <johnthetubaguy> lakshmiS: yeah, API changes are the only thing we require a spec for in Nova, be it a bug fix or a feature
14:37:25 <malini> mfedosin -- https://review.openstack.org/#/c/200980/ does not change any API, no spec -- am I missing something,
14:37:40 <mclaren> Specs have a reputation for slowing things down, in the case of API changes that actually may not be a bad thing
14:38:01 <jokke_> malini: read the review comments ... there is pretty valid statement it actually changing the v1 API
14:38:02 <mfedosin> malini, before if we put is_public='on' it returned None, but with this patch it becomes True.
14:38:27 <johnthetubaguy> mclaren: +1 it sounds terrible like that, but you really need to sit back and think about the problems the change can cause
14:38:42 <jokke_> ++
14:38:57 <sigmavirus24> mfedosin: good catch
14:39:08 <nikhil_k> I think we have had some issue with the DB migration / schema changes in Glance
14:39:50 <nikhil_k> Some deployments had corruption of data with changes merged in without much context where a spec would be have been really benefitial
14:41:39 <mclaren> to give a concrete example (a bug fix) https://review.openstack.org/#/c/199104 this is the kind of thing we'd define a mini-spec for?
14:41:52 <sigmavirus24> mclaren: I'd say yes
14:42:02 <sigmavirus24> mclaren: that's the kind of thing that's mildly backwards incompatible
14:42:18 <sigmavirus24> I think 200980 is mildly backwards incompatible too but in a different way
14:43:05 <jokke_> in that context ... and specifically this mentioned change ... could we please stop doing changes like this just "because oslo" for the bits of the code we have agreed that we fix only criticals as we try to deprecate it
14:43:06 <mclaren> the specs would then act as reference for similar future changes, like common law
14:43:14 <wxy_> '
14:43:58 <jokke_> I think this is good example of doing "totally harmless" change in benefit of using someone elses reinvented wheel and by that causing a change to API we try to deprecate
14:46:08 <nikhil_k> Ok, we need to move on for now.
14:46:19 <nikhil_k> #topic Reviews, Bugs and Releases
14:47:06 <nikhil_k> #link      https://review.openstack.org/199378
14:47:30 <sigmavirus24> That was me
14:47:36 <sigmavirus24> This ties in with our micro specs discussion
14:47:46 <sigmavirus24> That's a tiny change that corrects the behaviour of the API
14:48:00 <sigmavirus24> And yes, the behaviour they're suggesting is correct.
14:48:26 <sigmavirus24> That said, it will mean a change in the behaviour which (while again, no one should be relying on it) will be somewhat backwards incompatible
14:48:56 <nikhil_k> umm, I doubt if this needs to throw a NotFound
14:49:11 <nikhil_k> the image exists, data doesn'
14:49:40 <sigmavirus24> nikhil_k: this is specifically for download
14:49:46 <mclaren> Does anyone know what other projects do about this kind of change? As far as I know swift are ultra conservative, but I'm not sure about others, or if there are guidelines anywhere
14:50:09 <sigmavirus24> mclaren: the API WG hasn't written guidelines for making changes like this
14:50:33 <jokke_> sigmavirus24: personally I think that should be their top priority then ;)
14:50:38 <sigmavirus24> We've discussed it but frequently punted on it to define actual api behavour instead of development behaviour
14:50:53 <nikhil_k> sigmavirus24: hmm, I see the file bit is NotFound :/
14:50:55 <sigmavirus24> jokke_: the wg has different goals that are focused on api behaviour more than development of APIs
14:51:18 <sigmavirus24> nikhil_k: yeah if you can't find the image data to download, 404 is the least objectionable error code here
14:51:30 <nikhil_k> But it's confusing given we define that a image not in active status doesn't have image data
14:51:46 <jokke_> sigmavirus24: maybe it should be defcores priority then as they are driving ultra concervatism towards stable apis
14:52:09 <sigmavirus24> jokke_: or just an openstack-spec
14:52:31 <jokke_> and current behavior is that we return 204, which IMO is correct. The image exists, it does not have content
14:52:33 <sigmavirus24> perhaps written by defcore members, but put in place for openstack
14:52:59 <nikhil_k> #link https://review.openstack.org/#/c/199104/
14:53:12 <nikhil_k> trying to move faster in the interest of time
14:53:20 <sigmavirus24> that one is a review by bunting
14:53:38 <mclaren> nova have microversions so I guess you can just bump the version if you fix one of these -- a user can still supply the old version in their request header to continue getting unchanged behaviour (in principle)
14:53:55 <sigmavirus24> mclaren: and I seem to agree that people probably aren't relying on this, but we'll need an API version bump
14:54:01 <jokke_> ok, tl;dr will this affect only update?
14:54:03 <sigmavirus24> I'm not sure if we want to do that
14:54:07 <malini> But no decision was made on https://review.openstack.org/199378 !!
14:54:26 <sigmavirus24> malini: we don't need to make decisions here
14:54:33 <sigmavirus24> Just bring the reviews to people's attention
14:55:18 <nikhil_k> I think we have been trying to bump up the v2 versions when we see changes like these
14:55:45 <malini> sigmavirus24 -- :-) my first glance IRC meeting, thank you!
14:56:11 <nikhil_k> #link https://review.openstack.org/#/c/195820/
14:56:29 <nikhil_k> I looked at that one last week but forgot to comment :/ (while in the middle of a meeting)
14:56:55 <mclaren> nikhil_k: yes, but my understanding is that in glance the version is just informational, whereas in nova you can send the old version in a header to get 'guaranteed' unchanged behaviour
14:57:32 <nikhil_k> mclaren: I think we may soon have to move towards that. Once we know more from the DefCore team in the late july.
14:57:45 <jokke_> yes, we just inform that we have different api versions, they do not make it backwards compatible
14:57:58 <nikhil_k> We just need to agree on a stable API and then establish a pattern for micro=version upgrades for the following years
14:58:11 <mclaren> nikhil_k: ok, interesting. I wonder if that's a big amount of work...
14:58:20 * nikhil_k shrugs
14:58:23 <sigmavirus24> nikhil_k: that last link is more of a "I'd like more people to look at this"
14:58:48 <sigmavirus24> That looks like an important change that wayne__ needs to move through for metadefs to function appropriately and so far, very few people are reviewing it
14:58:53 <jokke_> wayne__: do we have other options than change that?
14:59:01 <nikhil_k> Thanks sigmavirus24 , it would be nice to get diverse reviews on that on specifically
14:59:30 <sigmavirus24> jokke_: do you have suggestions for how to fix database problems other than with a migration?
14:59:51 <nikhil_k> I agree that models should have been changes, so shoud have been for images+image-members
14:59:58 <nikhil_k> so +2 from me on that proposal
15:00:09 <nikhil_k> changed*
15:00:22 <wayne__> jokke_: change the need for unique constraints?
15:00:22 <jokke_> sigmavirus24: I do not do databases, that's why I asked ... because if we do not have other options, then I'm in favor to do it now rather than later ;)
15:00:27 <nikhil_k> Ok, we can roll over a couple of mins
15:00:37 <nikhil_k> As I am chairing the next meeting :P
15:00:48 <lakshmiS> :)
15:00:50 <nikhil_k> #info python-glanceclient release 0.17.2 https://review.openstack.org/#/c/202559/ && https://review.openstack.org/202564
15:00:58 <nikhil_k> jokke_: was that you?
15:01:02 <jokke_> yes
15:01:17 <jokke_> the release management team is working with nifty way to do lib releases
15:01:25 * nikhil_k like
15:01:41 <wayne__> I don't know any other way to do it that would ensure the uniqueness of the data.
15:01:50 <nikhil_k> kragniz: what's news on glance_store release 0.7.0 ?
15:02:02 <jokke_> there is new repo where the releases are yaml docs, you request a new release by changing the correlated file with new version number and change id you'd like to tag
15:02:10 <kragniz> haypo's been asking for a new release for a while
15:02:27 <nikhil_k> I guess you and haypo have the answer above
15:02:33 <kragniz> anyone have any problems with releasing what's currently in head?
15:02:34 <sigmavirus24> we're over time
15:02:36 <jokke_> wayne__: fair enough ... as said in that case I'm in favor without understanding the details what's going on at that change ;)
15:02:50 <nikhil_k> sigmavirus24: thanks for pointing that out.
15:03:01 <sigmavirus24> let's move to #openstack-glance
15:03:08 <sigmavirus24> #openstack-searchlight is supposed to be meeting now
15:03:10 <jokke_> yeah ... thanks all
15:03:15 <kragniz> thanks
15:03:16 <nikhil_k> Thanks all for joining
15:03:16 <mfedosin> thanks
15:03:22 <nikhil_k> #endmeeting