14:00:05 <rosmaita> #startmeeting glance
14:00:06 <openstack> Meeting started Thu Nov  3 14:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:10 <openstack> The meeting name has been set to 'glance'
14:00:12 <rosmaita> #topic roll call
14:00:39 <sigmavirus> o/
14:00:48 <abhishekk> o/
14:01:49 <rosmaita> abhishekk: have you filed a bug for the "community goal" yet (remove incubated oslo code), or would you like me to do that?
14:02:08 <stevelle> o/
14:02:14 <abhishekk> i am going to file that tomorrow
14:02:20 <abhishekk> I am working on the patch now
14:02:44 <abhishekk> rosmaita: is it ok?
14:02:51 <alex_bash> o/
14:02:53 <rosmaita> abhishekk: ok ... i think i will file it today and send you the bug #
14:03:11 <rosmaita> or will it be easier if you do it?
14:03:14 <abhishekk> rosmaita: thank you, that way is also good
14:03:26 <hemanthm|away> o/
14:03:31 <rosmaita> #action rosmaita to file "community goals" bug for glance
14:03:42 <rosmaita> hello everyone
14:03:48 <rosmaita> kind of light turnout today
14:03:54 <rosmaita> but high-quality!
14:04:17 <rosmaita> bunch of stuff on the agenda but it should go fairly quickly
14:05:02 <rosmaita> #topic updates
14:05:22 <rosmaita> ok, we discussed the priorities at the summit
14:05:35 <rosmaita> #link https://etherpad.openstack.org/p/ocata-glance-prioritization-and-roadmap
14:05:56 <rosmaita> i think thre are no surprises on there
14:06:28 <rosmaita> as far as #3 goes, Rolling Upgrades + Zero Downtime DB Migrations
14:06:48 <rosmaita> hemanthm and alex_bash will present a virtual design summit next friday (11 November)
14:07:09 <rosmaita> time and communication protocol to be determined
14:07:32 <rosmaita> look for an announcement on the ML within the next few days
14:07:58 <rosmaita> i've said this before, but the point of the virtual design summit session
14:08:14 <rosmaita> is to make sure all glance active contributors and cores are on board with the plan
14:08:24 <Jokke_> o/
14:08:33 <rosmaita> which is to switch from sqlalchemy-migrate to alembic for DB migrations
14:08:54 <rosmaita> and to use db triggers to handle complicate data migrations with zero downtime
14:09:25 <rosmaita> the other update is the timeline for Ocata development
14:09:39 <rosmaita> #link https://releases.openstack.org/ocata/schedule.html
14:10:04 <rosmaita> For Glance, there's a spec proposal freeze and then a spec freeze two weeks later
14:10:38 <rosmaita> times and dates are on that page
14:10:49 <rosmaita> (i'm not typing them in here in case i make a typo)
14:11:10 <rosmaita> there's some more fine-grained info on the etherpad
14:11:20 <rosmaita> #link https://etherpad.openstack.org/p/ocata-glance-prioritization-and-roadmap
14:11:39 <rosmaita> the key thing right now is that Ocata-1 milestone is week of Nov 14
14:11:53 <rosmaita> i'd really like to see community images merged by then
14:12:01 <stevelle> nice etherpad there btw
14:12:07 <rosmaita> ty
14:12:54 <rosmaita> ok, i think that's all the updates, any questions?
14:13:46 <rosmaita> (i am trying to wait 1 minute before proceeding)
14:14:07 <rosmaita> #topic draft logo of glance mascot
14:14:20 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/2016-October/106235.html
14:14:33 <Jokke_> I think we need to push back on this
14:14:39 <rosmaita> i thought you'd say that
14:14:44 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/2048ba97/attachment.jpeg
14:14:49 <rosmaita> that link is more to the point
14:15:04 <Jokke_> I don't see our key requirement as in the nuts being taking into an account :P
14:15:09 <rosmaita> exactly
14:15:32 <rosmaita> also, i showed it around and the feedback i got was "why do you have a squirrel as your logo?"
14:15:49 <rosmaita> so it's not "obviously" a chipmunk
14:16:02 <rosmaita> (and i'm not sure the text "chipmunk" is part of the logo)
14:16:03 <Jokke_> tbh, looking the outcome and the time it took to get there, I kind of feel like they didn't want to even think the original feedback given when this project was started
14:16:16 <rosmaita> did you watch that video?
14:16:21 <Jokke_> no I did not
14:16:30 <rosmaita> it started with the original picture we had of the chipmunk
14:16:35 <rosmaita> with mouth stuffed with nuts
14:16:42 <rosmaita> and then morphed into what we have here
14:16:45 <Jokke_> but yes, it does look more of an squirrel and we're missing the key point on it
14:16:57 <rosmaita> it's like 1/2 second of the video, about 70% through
14:17:01 <Jokke_> ah it was actually us specific video
14:17:14 <rosmaita> oh, didn't realize that
14:17:22 <Jokke_> I need to look that ... I thought it was the general marketing video of these logos and skipped it
14:17:43 <hemanthm> it was a general video I think
14:17:47 <Jokke_> ah
14:17:48 <rosmaita> for anyone who didn't watch it, the video is extremely short and actually kind of interesting
14:17:55 <Jokke_> ok, cool
14:18:12 <rosmaita> #link https://youtu.be/JmMTCWyY8Y4
14:18:28 <Jokke_> still even they provided nice video, lets use the feedback and push back on that logo
14:18:31 <rosmaita> but, that brings us back to the main point ... do we as a community want to provide feedback
14:18:52 <rosmaita> i am ok with doing that (even though i voted for the saber-tooth tiger)
14:19:06 <rosmaita> (which woudl not be mistaken for a squirrel)
14:19:35 <rosmaita> should i take a vote to get a sense of the community on this, or does everyone agree with Erno?
14:20:07 <rosmaita> the issue, for those joining us late, is that we specifically asked for a chipmunk whose mouth was stuffed with nuts
14:20:19 <rosmaita> to illustrate the chock-full goodness of a glance image store
14:20:35 <stevelle> I gave feedback already that per the msg to the list (it looked too much like one of the other logos seen in the video)
14:20:58 <rosmaita> stevelle: you used the feedback form?
14:21:02 <stevelle> yes
14:21:05 <Jokke_> https://youtu.be/JmMTCWyY8Y4?t=41 for the inpatient
14:21:37 <rosmaita> Jokke_: ty!
14:22:25 <rosmaita> OK, how's this: i will convey official feedback from the community that we'd appreciate a re-draft, and also individual glancers should provide feedback on the form
14:22:28 <rosmaita> stevelle: ty
14:22:37 <Jokke_> rosmaita: ++
14:22:40 <stevelle> and tipping my hat to Jokke_ I mentioned "squirrel" as well
14:22:49 <rosmaita> #action rosmaita respectfully ask logo mavens for a re-draft per out spec
14:22:57 * sigmavirus will also provide feedback
14:23:08 <rosmaita> #action everyone provide feedback on form http://tinyurl.com/OSmascot
14:23:09 <sigmavirus> I don't care as much, but I don't want to be confused for another project
14:23:18 <rosmaita> sigmavirus: ++
14:23:39 <rosmaita> ok, moving along
14:23:59 <rosmaita> #topic retain or delete setup/teardown that don't do anything other than call the superclass setup/teardown?
14:24:20 <rosmaita> this came up on a recent patch, and i would like some feedback
14:24:21 <rosmaita> https://review.openstack.org/#/c/372934/
14:24:52 <rosmaita> i guess the issue is explained on the patch
14:25:05 <sigmavirus> So, this can **marginally** improve test times because we're reducing one item from the stack when setup/teardown are called
14:25:30 <rosmaita> yeah, i figured it would be pretty marginal
14:25:36 <sigmavirus> It's also nice to have a patch that's *just* deletions
14:25:42 <stevelle> hah
14:25:56 <sigmavirus> I'm also not convinced that keeping them will have any benefit
14:26:16 <sigmavirus> I'm just miffed about all these patches that take attention away from priorities and provide little real benefit to the project, community, or users
14:26:31 <rosmaita> i guess i'm bringing this up because they've always been there, and i wanted to make sure there was no reason to keep them
14:26:39 <sigmavirus> So take that as a "I have no clue what to do here because by merging these we encourage them and by ignoring them we're ignoring some tiny technical debt"
14:26:41 <Jokke_> sigmavirus: ++
14:26:44 <rosmaita> sigmavirus: i share your miffed-ness
14:27:13 <rosmaita> and i agree with Jokke_ , sigmavirus has summed up the issue nicely
14:27:33 <rosmaita> actually, i guess this is related to the next item, too
14:27:41 <rosmaita> but i should probably stay focused on this
14:27:51 <rosmaita> for another minute anyway
14:28:09 <rosmaita> my feeling is that on balance, it's better to leave them than remove them
14:28:20 <rosmaita> but it's not an evidence-based feeling
14:28:25 <Jokke_> so this kind of belongs to that category Fei Long pointed out as "just merge it" with single type corrections in the docs ... if correct that they are indeed not needed. And well the proposed change did not change anything else than the tests and did not break the tests which indicates it might well be correct assesment
14:29:10 <rosmaita> what i'm thinking is that having the stubs there may be helpful for people writing new tests, may save them some developer time
14:29:19 <rosmaita> which is more expensive than VM cycles
14:29:26 <sigmavirus> rosmaita: that's not convincing to me honestly
14:29:30 <stevelle> from a test framework pov it is a correct / harmless change. from value to other developers, rosmaita has a point. I'm conflicted
14:29:38 <sigmavirus> "Someone might be able to just add to these methods in the future" is not convicing
14:29:54 <sigmavirus> That someone can also just add these methods back where necessary
14:30:06 <sigmavirus> On the whole, I'm -1 on effect-less changes though
14:30:09 <Jokke_> But I do have gut feeling issue with these certain entities proposing such blanket changes across the projects without ever having a plan to participate furter or be integrated part of the community and become very pestering if you don't approve their patches
14:30:13 <sigmavirus> And in reality, this change has no effect
14:30:32 <stevelle> I would default towards allow it, as Jokke_ suggested.
14:30:46 <rosmaita> sigmavirus: well, key thing is that these stubs pass tests, if you have to make up new ones, you may have a typo, etc, and waste time fixing
14:31:11 <rosmaita> but, i am willing to let the deletion go through if the community is cool with that
14:31:15 <sigmavirus> rosmaita: I make typos writing tests for other projects using setup/teardown and it takes me ... not very long to fix it
14:31:31 <sigmavirus> I'm leaning more towards, not accepting this though so it doesn't matter ;)
14:31:38 <sigmavirus> I'm just not convinced by that argument is all
14:31:50 <Jokke_> the only benefit I see keeping them at this point is consistency
14:31:58 <sigmavirus> Put it like this, testtools yells at you if you don't call super in setup/teardown
14:32:05 <sigmavirus> so that's an easy to debug thing
14:32:11 <alex_bash> +1 allow removal (cleaner, simpler, easier to read code)
14:32:11 <Jokke_> if we need them somewhere and potentially need them in future, lets be consistent and have them across
14:33:23 <sigmavirus> alex_bash: I don't see it as being easier or harder to read with or without them
14:33:26 <Jokke_> we have always valued consistency over debatable "better" solution
14:33:48 <alex_bash> less code on the page ==> easier to read
14:34:04 <Jokke_> alex_bash: that's very much untrue
14:34:31 <Jokke_> alex_bash: I can point you to some of very compact perl stuff if you need to be convinced :P
14:34:44 <sigmavirus> Jokke_++
14:34:45 <rosmaita> ok, don't want to spend too much time on this
14:34:51 <sigmavirus> Jokke_: I can do the same with python
14:34:58 <stevelle> when perl is invoked I think we lost the thread
14:35:05 <Jokke_> ;)
14:35:18 <rosmaita> how about, anyone interested, please leave a comment on the patch before 16:00 tomorrow
14:35:25 * alex_bash prefaces previous statement with: "in this particular case"
14:35:44 <rosmaita> #action anyone interested, please leave a comment on the patch before 16:00 tomorrow
14:36:03 <Jokke_> so in summary on my thoughts, I have hard time seeing the benefit of these changes specially when it will cause inconsistency
14:36:25 <rosmaita> i think that's a good point, but that's just me
14:36:33 <rosmaita> ok, moving on to a similar topic
14:36:37 <hemanthm> Jokke_: +1
14:36:48 <rosmaita> #topic strategy for handling the recent influx of typographical error fixes
14:36:58 <rosmaita> ok i have some links on the etherpad
14:37:27 <rosmaita> #link https://review.openstack.org/#/c/391388/
14:37:45 <rosmaita> i -2'd this one, everyone else feel free to do same
14:38:07 <rosmaita> no point fixing misspellings in comments unless they materially affect what's being stated
14:38:24 <rosmaita> like a typo in a RFC number or something
14:38:41 <rosmaita> #link https://review.openstack.org/#/c/391388/
14:38:49 <hemanthm> rosmaita: there is nothing wrong in fixing typos but if someone wants to fix typos they better fix all the typos instead of submitting a patch for each occurrence
14:38:49 <rosmaita> this one, i'm inclined to reject, too
14:39:00 <rosmaita> hemanthm: i'll address that in a minute
14:39:18 <rosmaita> someone misspelled 'eventlet' as part of a test name
14:39:42 <hemanthm> https://review.openstack.org/#/c/393245/
14:39:47 <rosmaita> i don't see the point of messing with it, but it's not as obvious to me for some reason as the previous case
14:39:53 <rosmaita> hemanthm: ty
14:40:32 <rosmaita> just wondering if anyone had a strong opinion?
14:40:49 <rosmaita> basically, i'd like us to be able to -2 wihtout even thinking about these
14:41:13 <rosmaita> i'll update the "disallowed code changes" to reflect these
14:41:34 <rosmaita> ok, the other case, is similar to what hemanthm mentioned
14:41:45 <rosmaita> #link https://review.openstack.org/#/c/390566/
14:41:47 <Jokke_> so I totally agree with not fooling around on the in-code comments (not docstrings as they are used for public documentations)
14:42:02 <rosmaita> Jokke_: good point aobu the docstrings
14:42:13 <Jokke_> the one hemanth mentioned is quite a bit more visible and I wouldn't mind changing that
14:42:34 <rosmaita> yeah, so the change is "Openstack" should be "OpenStack"
14:42:40 <rosmaita> we discussed this at the summit
14:43:09 <rosmaita> in the past, people (i.e., us) have been good aobut pointing out that there were "Openstack" occurrences that the change missed
14:43:14 <Jokke_> also we need to remember that the one thing these changes really mess up is git blame ... you try to see what was the context of the comment in the code and there is multiple change IDs involved
14:43:30 <rosmaita> Jokke_: another good point
14:43:37 <hemanthm> ++ Jokke_
14:43:41 <Jokke_> that really really winds me up way more than a typo in the comment itself
14:43:52 <Jokke_> as now I need to see why that comment was changed
14:44:32 <rosmaita> #action rosmaita update unacceptable changes doc including Jokke_ 's comments above
14:44:40 <rosmaita> ok, but back to the trivial typos
14:44:56 <rosmaita> we agreed at the summit, that we should just +2A these
14:45:10 <rosmaita> (trivial typos in user-facing stuff, i mean)
14:45:20 <rosmaita> don't even bother to grep to see if they hit them all
14:45:26 <rosmaita> it's too much of a waste of time
14:45:47 <rosmaita> sure, some people will do 10 patches instead of 1
14:46:03 <rosmaita> but as long as the patch is correct, just ninja-approve it
14:46:16 <sigmavirus> We should document that
14:46:21 <sigmavirus> (Not just in a meeting)
14:46:24 <rosmaita> so ... that's the proposed strategy, any commments?
14:46:56 <Jokke_> rosmaita: so that was documentation only IIRC
14:46:58 <Jokke_> ?
14:47:05 <rosmaita> sigmavirus: yes, i will document, though i don't want to put it on the ML, because i don't want to encourage people to do this
14:47:19 <Jokke_> rosmaita: ++
14:47:32 <rosmaita> Jokke_: that's a good point, the +2A is doc-only changes
14:47:44 <rosmaita> anything touching code should go through the normal 2 +2s
14:48:00 <rosmaita> though, typos in comments will be immediately -2d
14:48:31 <rosmaita> tell you what, i better write this up as a patch, and we can comment on the patch to make sure everythign is clear
14:48:43 <Jokke_> sounds good
14:49:00 <rosmaita> ok, so this discussion is basically notice that a patch is on the way
14:49:19 <rosmaita> #topic python-glanceclient passing a request-id
14:49:42 <rosmaita> meetingbot?
14:49:44 <rosmaita> hmmm
14:50:18 <abhishekk> hi, this is based on cross-project specs and I have created lite-specs https://bugs.launchpad.net/glance/+bug/1525259
14:50:18 <openstack> Launchpad bug 1525259 in Glance "Add request_ids attribute to v2 schemas" [Wishlist,Triaged] - Assigned to Abhishek Kekane (abhishek-kekane)
14:50:31 <rosmaita> ok, this is abhishekk has had a spec-lite up for this since the days when we did spec lites as bugs
14:50:58 <rosmaita> and i just noticed that the bug name is misleading
14:51:12 <abhishekk> we have one scenario here, update api has 3 internal calls 1. get image, 2. patch and 3. get updated image
14:51:55 <abhishekk> for this purpose I have implemented like request-id of patch call will be passed to next get call so that we can have identical request-ids
14:52:13 <abhishekk> rosmaita: I will update the name
14:52:19 <rosmaita> abhishekk: ty!
14:53:30 <abhishekk> so I want opinions of glance cores on this approach
14:53:41 <Jokke_> abhishekk: thanks for looking out ofr these corner cases and bringing them up
14:53:44 <rosmaita> basically, abhishekk and colleagues figured out a way to do this without changing the schema
14:54:01 <rosmaita> here's the patch: https://review.openstack.org/#/c/352892/
14:54:13 <abhishekk> rosmaita: we have used wrapt module in python-novaclient as well
14:54:43 <abhishekk> jokke_: thanks, I have got your help in addressing this
14:55:10 <rosmaita> the approach looks good to me, would be good to have some more core opinions though
14:55:47 <rosmaita> abhishekk: any other comments?
14:56:12 <abhishekk> rosmaita: no, thank you
14:56:22 <rosmaita> #topic open discussion
14:56:29 <abhishekk> abhishekk: early feedback will help us to get this in
14:56:44 <rosmaita> we only have 3 min left, but there's no searchlight meeting today, so we have a bit more time
14:57:01 <rosmaita> meetingbot is slow to change topics today
14:57:10 <rosmaita> anyone have anything to discuss?
14:58:17 <alex_bash> Here's the doodle poll for next Friday's virtual design session/demo of rolling upgrades: http://doodle.com/poll/tybifi4qyk8stbgz
14:58:35 <rosmaita> alex_bash: ty
14:58:55 <rosmaita> #action everyone look at poll to select session time: http://doodle.com/poll/tybifi4qyk8stbgz
14:59:02 <rosmaita> #link http://doodle.com/poll/tybifi4qyk8stbgz
14:59:17 <rosmaita> anything else?
14:59:39 <rosmaita> ok, there's always #openstack-glance for discussion
14:59:47 <rosmaita> thanks everyone!
14:59:59 <rosmaita> #endmeeting