14:00:23 <rosmaita> #startmeeting glance
14:00:24 <openstack> Meeting started Thu Apr  6 14:00:23 2017 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <openstack> The meeting name has been set to 'glance'
14:00:36 <rosmaita> #topic roll call
14:00:42 <stevelle> o/
14:00:42 <hemanthm> o/
14:00:46 <dharinic> \o
14:01:08 <jokke_> o/
14:01:46 <rosmaita> guess we have a quorum
14:01:56 <rosmaita> hello everyone
14:02:09 <dharinic> Hello. :)
14:02:28 <rosmaita> reminder:
14:02:30 <rosmaita> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:36 <rosmaita> ok, first item
14:02:53 <rosmaita> #topic updates - P-1 deadline
14:03:13 <rosmaita> as hemanthm announced last week, today is the deadline for fixes to get into P-1
14:03:38 <rosmaita> unfortunately, there are pypi mirror problems that are causing some of the py35 tests to fail intermittently
14:04:08 <rosmaita> mordred is running a sync by hand right now
14:04:20 <rosmaita> so by the time the meeting is over, things should be back to normal
14:04:53 <rosmaita> i have a question that i don't have any answers too, though
14:05:08 <rosmaita> nameley what to do about glance_store and glanceclient for P-1
14:05:25 <rosmaita> i dropped the ball in setting any priorities for them
14:05:42 <rosmaita> i am tempted to wait until P-2 to release new ones?
14:05:56 <rosmaita> wondering if there are any contrary opinions
14:05:57 <hemanthm> we can look at what changes went in after Ocata and take a call maybe?
14:06:18 <rosmaita> i think the problem is that some reviews have been sitting awhile
14:06:25 <jokke_> So we don't generally need to worry about the milestones in our lib releases unless we need new release for the milestones
14:06:26 <rosmaita> so not much new has gone in
14:06:32 <jokke_> they are not otherwise linked
14:06:37 <rosmaita> jokke_: ty
14:06:56 <hemanthm> no, we don't need to release clients/libraries as per milestones
14:07:02 <rosmaita> i think there are some current patches up for glanceclient that will be useful for nova
14:07:17 <rosmaita> so we could release when ready, out-of-band
14:07:20 <rosmaita> ?
14:07:22 <hemanthm> yep
14:07:28 <rosmaita> ok cool
14:07:49 <hemanthm> there's a deadline for client and non-client libraries towards the end of the cycle
14:07:53 <hemanthm> nothing in between
14:07:54 <rosmaita> i will be better this time about targeting some fixes for P-2 so we can give the glance_store and glanceclient some love
14:08:08 <rosmaita> ok, thanks
14:08:19 <rosmaita> #topic update - spec freeze
14:08:37 <rosmaita> just a reminder that hte spec freeze is next week, for people working on specs
14:08:50 <rosmaita> thanks for the reviews, things are moving along
14:08:57 <rosmaita> we'll talk more in a bit
14:09:01 * jokke_ will spend tomorrow reviewing any outstanding specs
14:09:31 <rosmaita> jokke_: there is a special one for you, actually
14:09:38 <jokke_> :)
14:09:47 <rosmaita> #topic update - there is no "reverify"
14:10:07 <rosmaita> just a quick reminder for people that missed the email
14:10:17 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114828.html
14:10:29 <rosmaita> you can only "recheck" on patches now
14:10:52 <rosmaita> they're not kidding, either ... i saw a few patches this morning where 'reverify' did nothing
14:11:03 <rosmaita> so, just be aware
14:11:23 <rosmaita> i went to a qa demo at the PTG where they explained why, but i forget the reasoning
14:11:28 <jokke_> rosmaita: thanks for the heads-up
14:11:38 <rosmaita> anyway: "recheck" only!
14:11:41 <dharinic> Thanks rosmaita. I ussed a reverify last night on the cache patch.
14:11:54 <rosmaita> dharinic: yes, that's the one i noticed
14:12:05 <jokke_> sounds like they have some extra resources in the CI pool that needs usage to justify their existence ;)
14:12:49 <dharinic> I had an assumption that reverify = recheck + merge.
14:13:19 <jokke_> dharinic: no reverify used to skip the check and do just gate, if it succeeded then merge
14:13:20 <rosmaita> dharinic: there used to be a difference, then they decided to make them the same operation
14:13:32 <rosmaita> and now they've removed the alias
14:13:40 <dharinic> Hmmm, Thanks.
14:13:45 <jokke_> recheck used to run (if +W) check, gate and merge
14:13:59 <rosmaita> they had usage data that showed that there wasn't a savings by not running everything
14:14:12 <rosmaita> so now they just run it all all the time
14:14:43 <rosmaita> ok, did i ask if anyone else had an announcment? any of the cross-project liasons?
14:15:29 <rosmaita> guess not ... moving along, then
14:15:39 <rosmaita> #topic spec review
14:15:49 <rosmaita> ok, let's all open the etherpad
14:15:59 <rosmaita> #link https://etherpad.openstack.org/p/glance-pike-specs-review
14:16:25 <rosmaita> this is up to date, i just checked everything
14:16:37 <rosmaita> well, was up to date as of beginning of the meeting
14:16:50 <rosmaita> first, though, i have some concerns i need to express
14:17:39 <rosmaita> some glancers have communicated to me that they will not have time to work on glance, probably starting in the next 2 weeks
14:17:45 <rosmaita> i will let them announce when appropriate
14:18:03 <rosmaita> but the reason i bring it up is that we are going to be low on dev-power to finish the cycle
14:18:12 <rosmaita> and, we are looking at some cool specs
14:18:40 <rosmaita> so i want to make it clear (and guess i should send this out to the ML)
14:18:44 <nikhil> How many glancers?
14:19:07 <hemanthm> I would say low on review-power too
14:19:12 <rosmaita> well, ian is gone, 2 more active peeps
14:19:17 <rosmaita> hemanthm: ++
14:19:33 <rosmaita> although, i mean simply agreement there, not that it's a good situation
14:20:03 <rosmaita> sorry, i am having trouble typing what is in my brain
14:20:33 <rosmaita> what i want to say is, i believe that the glance policy has been that we accept specs to indicate they are worthy
14:20:40 <jokke_> I'd like to ask if any of those people has spec proposed to indicate it quick. We do not want to prioritize something over other and end up to the situation where the one we accepted does not have interest to complete and the one we postponed would have got dev just waiting to work on it
14:20:46 <rosmaita> we then set priorities on the ones we want to accomplish
14:20:56 <rosmaita> and other stuff is subject to bandwidth
14:21:17 <hemanthm> rosmaita ++
14:21:25 <rosmaita> so being accepted in pike but not prioritized indicates that it mighnt not make it into pike
14:21:31 <rosmaita> but then again it could
14:21:47 <rosmaita> and the more reviews you do of other peoples' code, the more likely your stuff is to be reviewed
14:21:59 <rosmaita> so to folow up jokke's point
14:22:15 <rosmaita> the prioritized specs should be the ones we think can get done
14:22:27 <rosmaita> the accepted ones are specs taht we will review subject to bandwith
14:22:37 <rosmaita> what i mean is
14:22:58 <rosmaita> i don't want to -2 proposals because i;m not sure we can get to them
14:23:08 <rosmaita> but, the situation is, we may not get to them
14:23:17 <nikhil> Yeah, accepted merely means or used to mean (whatever) -- "ok" on direction
14:23:27 <rosmaita> a complicating factor is that most of us have employers
14:23:38 <rosmaita> who may put pressure for stuff to get done
14:23:55 <rosmaita> so, i want to be able to approve specs that are good
14:24:18 <rosmaita> and then the people working on the spec can facilitate gettting stuff into pike by reviewing other people's patches
14:24:29 <rosmaita> espcially, and mostly, the priority items
14:24:42 <rosmaita> (i think i'm just restating current policy)
14:24:58 <jokke_> rosmaita: nothing wrong with that ^^
14:25:05 <rosmaita> i'll put that into an email, i think our meeting time is pretty APAC-unfriendly
14:25:18 <rosmaita> ok, cool
14:25:47 <rosmaita> that being said, let's do a quick runthrough of the spec etherpad (now with helpful links to the patches)
14:26:18 <rosmaita> 451560 needs a core to take a look
14:26:26 <rosmaita> (someone who is not me or dharinic)
14:26:46 <jokke_> I'd just like to remind as well that our specs have the key contact point for implementation. So reinforcing what I asked above if we get the key people dropping their glance mic and no replacement found, I'm also happy to propose reverts for those specs to not give false indication that those specs are under work
14:27:32 <hemanthm> rosmaita: will review that
14:28:13 <rosmaita> jokke_: that's a good point, if you've got a spec up and may not be here to complete it, please talk to other people about picking it up
14:28:44 <rosmaita> i think for today, most of the proposals are pretty good, and don't really require much more review time
14:29:08 <rosmaita> 450621, i think nikhil is working on an update for that one
14:29:21 <rosmaita> that's important because of the security implications
14:29:32 <nikhil> Yeah
14:29:38 <rosmaita> 206120 is awaiting response
14:29:56 <rosmaita> 442863 - that's the one jokke_ could provide helpful input on
14:30:17 <rosmaita> it also brings up a question, which i will ask becuase today's agenda is light
14:30:34 <rosmaita> how much implementation detail is appropriate for a spec-lite?
14:30:51 <rosmaita> we don't want to overprescribe design
14:31:36 <rosmaita> this spec points out a way to do it, but my comment is that i'd like to hear a little more
14:31:54 <rosmaita> anyway, was wondering if i am asking too much for a lite-spec
14:33:09 <rosmaita> anyway, feedback appreciated when you have some
14:33:22 <hemanthm> we shouldn't be limiting ourselves to add detail just because something is a lite-spec vs full spec
14:33:38 <jokke_> I like that proposal in general, what I would like to ask is that we do not bring in yet another config option and yet another stopfile but we hook into the healthcheck middleware which already has that and config for it
14:33:55 <jokke_> anyone has strict objections towards that?
14:34:06 <rosmaita> jokke_: whould there be a use case for stopping tasks independently of the entire api?
14:34:15 <rosmaita> i am thinking yes
14:34:28 <jokke_> rosmaita: so in the usecase the spec is proposing, no
14:34:35 <dharinic> Yes. And for a reviewer, without getting an idea of the implementation feasibility, (either put down on the lite-spec or assumed if obvious), it is tricky to +2
14:34:39 <stevelle> the existing middlware is not appropriate for async operations though
14:35:15 <stevelle> I want to avoid adding anything we don't need though
14:35:19 <rosmaita> so jokke_ you are thinking the use case is strictly take an entire node out of rotation for upgrade
14:35:22 <jokke_> stevelle: what I mean is we have via that middleware already one stopfile configured to put the node to maintenance
14:35:56 <jokke_> what I'm saying is, that we shoud tap to that same config option/file instead of implementing yet another one
14:35:56 <rosmaita> jokke_: i think you have a point, all-or-nothing maintenance mode
14:36:18 <jokke_> rosmaita: that's what the spec lite says
14:36:18 <rosmaita> and something more complicated could be done later if there is demand
14:36:22 <stevelle> are taskflow hosts always going to be running api?
14:36:58 <rosmaita> stevelle: that is a good point, there might be dedicated taskflow nodes
14:36:58 <stevelle> just a thing I want to be sure I don't mistake
14:37:22 <stevelle> the taskflow can use the same config I suppose either way
14:37:30 <rosmaita> we should continue this discussion on the patch
14:37:34 <jokke_> stevelle: we have no code up what so ever to do anything else atm. The API of that host might not be available for consumption (FW rules, network separation, etc) but only way to have worker is to run glance-api
14:37:48 <rosmaita> thanks jokke_ and stevelle
14:38:08 <rosmaita> ok, 448680 just got updated
14:38:26 <rosmaita> so it needs review ... i've got that one and really like it
14:38:35 <jokke_> #yeah if it's not felt as horribly awful idea I put review on the patch and we continue there
14:38:48 <stevelle> +1
14:38:56 <rosmaita> jcook: i think i would prioritize multihash over the downloads spec
14:39:12 <jcook> rosmaita I just updated that one
14:39:21 <rosmaita> ok the rest are awaiting responses
14:39:30 <rosmaita> except for 436581
14:39:39 <rosmaita> the db-sync check feature
14:39:41 <jcook> I'm going to try to get to downloads spec today
14:40:24 <rosmaita> 436581 needs review
14:41:00 <rosmaita> i thik hemanth had a concern, though
14:42:08 <hemanthm> not a concern
14:42:25 <hemanthm> we are definitely forgetting something we thought we should add to the spec at PTG
14:42:26 <rosmaita> maybe more of a scope questions?
14:42:56 <hemanthm> yeah, expanding the scope of it
14:43:22 <hemanthm> I'll spend more time on it but nothing to block the spec
14:43:32 <jokke_> so which download you're talking about?
14:43:55 <jokke_> random access from cache or eliminating multiple downloads of uncached?
14:43:56 <hemanthm> redundant downloads spec I think
14:44:35 <jcook> oh me, yeah redundant downloads
14:44:38 <rosmaita> i have a scope question about the radom-access spec (on the spec)
14:44:56 <dharinic> will respond to it rosmaita
14:44:57 <rosmaita> i'll re-read the db sync and see if i can remember the PTG discussion
14:45:10 <rosmaita> ok, thanks for all the spec reviews, everyone
14:45:31 <rosmaita> #topic open discussion
14:45:53 <rosmaita> i notice that jokke_ put up a bunch of patches right before the meeting
14:46:09 <jokke_> yeah need to dump them in again
14:46:31 <jokke_> so ignore for now ... will see 'though if the rebasing solved the issues later on the chain
14:46:41 <rosmaita> ok, cool
14:47:01 <jokke_> I had remote messing my repo up and I ended pushing those patches out from wrong repo
14:47:25 <rosmaita> hemanthm: it looks like emilen is ok with waiting until pike-1 for the release version change to happen?
14:47:33 <hemanthm> rosmaita: yes
14:47:47 <hemanthm> he abandoned the patch
14:47:55 <hemanthm> I will include it in the release CPL docs
14:47:59 <rosmaita> i read through that stuff agian be before the meeting, think i understand it now
14:48:11 <rosmaita> sounds good
14:48:13 <jokke_> release version change?
14:48:20 <rosmaita> jokke_: don't ask!
14:48:33 <rosmaita> the deal is that there's a period of time
14:48:38 <jokke_> I did ... clearly something I have missed ;)
14:48:50 <rosmaita> after stable/ocata was cut and while we start pike
14:49:06 <rosmaita> where both master and stable/ocata are at version 14.0.0
14:49:13 <rosmaita> and it is confusing packagers
14:49:32 <rosmaita> so there's a way to tell pbr to increment the version in master before P-1 gets cut
14:49:44 <rosmaita> hemanth will doc that for the release CPL
14:50:17 <rosmaita> but, we won't do that special step because when we do P-1 today, the release version will be incremented appropriately
14:50:20 <jokke_> IIUC pbr should not allow packaging it if the version has been tagged already
14:50:26 <rosmaita> to 15.0.0.dev
14:50:55 <rosmaita> jokke_: not sure about that, there was something on the ML
14:50:56 <jokke_> or was that removed so that there is no need for version bump as first commit after cutting the stable branch?
14:51:40 <jokke_> 'cause it used to be that you couldn't even merge anything in before you had bumped the version, which was great and prevented such issues
14:51:59 <hemanthm> Do we version bump after cutting stable?
14:52:58 <hemanthm> If we are supposed to do that, maybe that's the source of confusion
14:53:01 <jokke_> hemanthm: I didn't look at this cycle but it has been the case. There has been always version bump proposed as first patch after tag/branch cut
14:53:23 <rosmaita> ok, then that explains it, i guess
14:53:31 <rosmaita> here's the ml thread: http://lists.openstack.org/pipermail/openstack-dev/2017-April/114991.html
14:53:54 <jokke_> and pbr didn't allow anything to merge if there was conflict of same version coming from multiple sources or same version coming with different output
14:53:57 <hemanthm> jokke_: I see, let me check. I don't remember seeing such a patch
14:54:51 <rosmaita> according to that thread, there were some changes made becaue of releasenote generation so that some things don't happen automatically any more
14:55:23 <jokke_> yeah ... well perhaps that somewhere is the right place to address it then ;)
14:55:50 <rosmaita> ok, i think we are ok for Pike
14:56:05 <rosmaita> and hemanthm 's update to the doc will set us up so we don't forget for Queens
14:56:16 <rosmaita> 4 minutes left
14:56:19 <rosmaita> any other items?
14:57:19 <jokke_> nothing from me
14:58:12 <rosmaita> ok, the mirrors should be up to date by now
14:58:25 <rosmaita> let's get the range-request patches merged
14:58:29 <hemanthm> maybe we can continue this on the glance channel but I was thinking about doing on-boarding events to encourage new contributors
14:58:41 <rosmaita> and hemanthm can declare P-1 on time
14:58:47 <rosmaita> hemanthm: ++
14:59:04 <rosmaita> glance channel for some brainstorming, but let's also put on the agenda
14:59:13 <hemanthm> once every two weeks or so, we announce a day where we encourage new folks to ask us questions, get reivews etc
14:59:23 <rosmaita> i like it
14:59:43 <rosmaita> we can alternate times for apac
14:59:51 <hemanthm> yeah
14:59:57 <rosmaita> ok, we're just about out of time
15:00:00 <jokke_> Thanks everyone!
15:00:01 <rosmaita> thanks, everyone!
15:00:06 <rosmaita> #endmeeting