15:00:08 <bswartz> #startmeeting manila
15:00:09 <openstack> Meeting started Thu Jul 21 15:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:12 <openstack> The meeting name has been set to 'manila'
15:00:16 <cknight> Hi
15:00:20 <dgonzalez> hi
15:00:21 <tpsilva> hello
15:00:26 <ganso> hello
15:00:28 <zengyingzhe_> Hi
15:00:29 <bswartz> hello all
15:00:29 <zhongjun_> hello
15:00:31 <vponomaryov> Hello
15:00:39 <jseiler> hi
15:00:39 <tovchinnikova> o/
15:00:40 <gouthamr> hello o/
15:00:40 <aovchinnikov> hi
15:00:44 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:00:46 <markstur_> hi
15:00:50 <tbarron> hi
15:00:55 <bswartz> very short agenda today
15:00:58 <rraja> hi
15:01:15 <bswartz> which is good because I'm hosting from ft collins at the cinder midcyce this week
15:01:26 <bswartz> #topic announcements
15:01:39 <bswartz> this major feature proposal freeze is today
15:01:45 <bswartz> s/this/the/
15:02:10 <xyang2> hi
15:02:15 <vponomaryov> and we have huge amount of already proposed big features ))
15:02:19 <bswartz> so all of the large features for newton should be proposed and reviewable already
15:02:35 <bswartz> vponomaryov: at least there won't be any more after today
15:03:17 <bswartz> zhongjun_: did you complete the share backup implementation?
15:03:38 <zhongjun_> yes, I already submit the share backup code to gerrit
15:03:39 <vponomaryov> bswartz: https://review.openstack.org/343980
15:04:04 <bswartz> thanks for link
15:04:21 <tpsilva> bswartz: I'll also push the mountable snapshots today, just finishing some stuff
15:04:46 <bswartz> okay so there's 6 weeks until feature freeze
15:05:15 <ganso> anything that will have related manila-ui patches will need to merge before 5 weeks from now, correct?
15:05:22 <bswartz> between now and then we want to spend our time reviewing and merging stuff that's ready and giving feedback to those that aren't
15:05:42 <bswartz> ganso: yes the UI freeze appears to be 1 week before feature freeze
15:06:02 <vponomaryov> bswartz: why so? it should be vice versa
15:06:06 <bswartz> at least that's my reading of the official community deadlines
15:06:15 <bswartz> vponomaryov: this isn't my call
15:06:17 <vponomaryov> bswartz: UI is dependent on server side features
15:06:28 <vponomaryov> ok
15:06:30 <ganso> vponomaryov: manila-ui is a library, it needs to be ready for horizon's FF I presume
15:06:33 <bswartz> I think any server feature that needs a ui should be done early then
15:06:48 <bswartz> many features don't need UIs and those have more time
15:06:55 <rraja> bswartz: i've added code that is reviewable for adding access_key to share_access_mapping. i'm not sure if it's a big feature though. https://review.openstack.org/#/c/343306/
15:07:21 <bswartz> rraja: well if it's done today then it doesn't matter because you met the deadline
15:07:44 <rraja> bswartz: ok.
15:07:49 <ganso> bswartz: so any core features that are less than 500 lines of code excluding tests are not considered major, correct?
15:07:54 <bswartz> looking at that review it seems to meet the definition of a "major feature" because it touches the API and DB
15:08:18 <bswartz> it's not many lines of code though
15:08:39 <bswartz> I'll look closer but probably this one will be easy
15:08:50 <rraja> bswartz: thanks!
15:08:57 <bswartz> okay on to the real agenda
15:09:08 <bswartz> #topic Migrate API reference into tree
15:09:16 <bswartz> dgonzalez: you're up
15:09:24 <gouthamr> #link: https://review.openstack.org/#/c/313874
15:09:36 <dgonzalez> Yeah, so gouthamr and I are currently moving the API reference in-tree
15:10:03 * bswartz complains gerrit is slow
15:10:13 <dgonzalez> We are nearly finished with teh work, and it would be great if people could start to have a look at it and review it
15:10:23 <gouthamr> update: everything that can be done on that patch is done wrt the content.. we're  only fixing an error with the parameters.yaml file
15:10:32 <vponomaryov> dgonzalez: in short, what is the diff with the source?
15:11:05 <dgonzalez> vponomaryov: what do you mean with diff?
15:11:16 <gouthamr> vponomaryov: the API reference is written differently -> no more unstructured RST or docbooks
15:11:29 <bswartz> you're rewritten all that RST into json?
15:11:40 <vponomaryov> dgonzalez: I am talking about data
15:11:52 <vponomaryov> dgonzalez: only container changes?
15:12:08 <gouthamr> vponomaryov: it will use an oslo tool called 'os-api-ref' to combine data from a structured RST and an accompanying parameters file to generate the API reference .. examples are still json files.
15:12:28 <bswartz> I think vponomaryov is asking if you changed any content or if the conversion was purely mechanical
15:12:29 <dgonzalez> bswartz: the json code are only the examples. teh actual reference is in the .inc files
15:12:43 <gouthamr> yes, changes are only corrections to the API documentation
15:12:45 <bswartz> I see
15:13:10 <vponomaryov> dgonzalez, gouthamr: thanks
15:13:23 <gouthamr> there is a (*cough* long) list of bugs that we'll be filing to the inconsistencies and errors in the API
15:13:30 <bswartz> thans for doing this dgonzalez, gouthamr
15:13:33 <gouthamr> some are minor and some are major
15:13:51 <gouthamr> i'll tag all of them so we can discuss them at an upcoming meeting
15:13:56 <gouthamr> thank god for microversions :)
15:14:13 <cknight> bswartz: +1   Thanks very much dgonzalez & gouthamr!
15:14:13 <bswartz> gouthamr: doc bugs or actual API bugs?
15:14:53 <dgonzalez> bswartz: I think he means doc bugs
15:14:54 <gouthamr> bswartz: actual API inconsistencies, like response keys, pagination mismatches, response codes and the like
15:15:04 <dgonzalez> ok, I was wrong :P
15:15:17 <gouthamr> dgonzalez: there will be doc bugs :)
15:15:26 <bswartz> gouthamr: you going to file a raft of bugs in LP then so we can get people to work on them?
15:15:39 * bswartz reconsiders...
15:15:42 <gouthamr> bswartz: yep
15:15:54 <bswartz> actually if we need lots of small fixes then it could make sense to bundle them up
15:16:00 <bswartz> to avoid microversion thrashing
15:16:13 <gouthamr> bswartz: we can take a look at these and see what needs to be fixed.. not all of them may need fixes per se..
15:16:19 <bswartz> okay
15:16:31 <bswartz> gouthamr: do you have the list now?
15:16:47 <gouthamr> bswartz: in an evernote
15:17:08 <gouthamr> bswartz: will do the LP filing today
15:17:16 <bswartz> okay
15:17:31 <bswartz> so since we have time I'll propose one more topic
15:17:37 <vponomaryov> gouthamr: please, mark all doc bugs with [doc] prefix
15:17:46 <gouthamr> vponomaryov: if they are doc, yes..
15:17:49 <gouthamr> will do :)
15:17:50 <bswartz> #topic prioritization for N-3 features
15:18:26 <bswartz> so it seems to me that given the large amount of reviews we need to do, that we need a way to organize that activity and make sure it happens
15:18:42 <bswartz> otherwise we'll end up a week before FF with nothing merged
15:19:03 <bswartz> any suggestions for a good way to manage this?
15:19:27 <bswartz> teams like cinder have created etherpads and sought "review volunteers"
15:19:44 <gouthamr> etherpad +1
15:19:55 <zengyingzhe_> good idea
15:19:59 <xyang2> +1
15:20:02 <zhongjun_> agree with etherpad
15:20:21 <markstur_> +1
15:20:30 <vponomaryov> review all in order of appearence
15:20:40 <bswartz> #link https://etherpad.openstack.org/p/manila-newton3-priorities
15:20:43 <vponomaryov> in cycle
15:21:14 <bswartz> there are 2 concerns
15:21:28 <bswartz> I'll set the actual priorities for the BPs in launchpad
15:21:43 <bswartz> the point of the etherpad isn't to prioritize as much as to ensure that things don't get ignored
15:22:33 <bswartz> so if you have a major feature please link it there and we'll get the list prioritized and create space for people to sign up to review
15:22:47 <bswartz> if anything looks ignored I'll go hunting for reviewers
15:23:02 <bswartz> the goal being to ensure everything gets timely feedback
15:23:15 <bswartz> of course there's no guarantee that anything will merge
15:23:23 <bswartz> I just want to avoid having everything merge at the last minute
15:23:39 <bswartz> sound good?
15:23:47 <tbarron> bswartz: +1
15:23:59 <bswartz> so please go ahead and post links there
15:24:13 <bswartz> I'll move them around and add anything I thing of, but I'm sure I'll miss a few
15:24:32 <bswartz> #topic open discussion
15:24:51 <bswartz> anything else for today?
15:24:56 <tpsilva> and please, for featues with a long list of patches (like share migration), let's try to review them in correct order
15:25:06 <tpsilva> this should avoid the rebase hell
15:25:11 <bswartz> tpsilva: good point
15:25:30 <bswartz> I'll sign myself up to help with those reviews
15:25:48 <bswartz> I'm excited about migration
15:26:09 <tovchinnikova> Speaking about reviews
15:26:19 <tovchinnikova> This change really needs some fresh opinions: https://review.openstack.org/#/c/336599
15:27:02 <bswartz> two +2 but -1 from vponomaryov
15:27:06 <tovchinnikova> It would be great to make our UI have new django
15:27:16 <bswartz> vponomaryov can you explain your problem with this?
15:28:04 <vponomaryov> bswartz: I am not agree calling tox job with specific version when it pulls always latest one
15:28:49 <vponomaryov> bswartz: I mean it has version in name when it pulls latest
15:28:49 <bswartz> it looks like the old code did this version thing too
15:29:11 <vponomaryov> yes, old code did it correctly
15:29:17 <bswartz> oh you mean the new change needs to have a ceiling on the version
15:29:21 <vponomaryov> version in name means we have such version
15:29:30 <vponomaryov> yes
15:29:31 <bswartz> yeah I think I agree with valeriy
15:29:52 <tovchinnikova> Discussion goes in circles :)
15:30:12 <bswartz> tovchinnikova:  why not put django<1.11 to match what the section name implies?
15:30:25 <bswartz> so you don't end up with 1.12 or 1.13
15:31:08 <bswartz> these was a clear pattern in the existing tox.ini but this change doesn't follow the pattern
15:31:12 <tovchinnikova> bswartz, in august we'll have django 1.10 and will have to fix the version line anyways
15:31:19 <tovchinnikova> now that's only beta
15:31:25 <bswartz> well I don't claim to understand why there are multiple sections
15:31:46 <bswartz> does anyone know why we have multiple versions listed here?
15:32:08 <vponomaryov> bswartz: they differ a lot
15:32:22 <bswartz> which one(s) get run?
15:32:31 <vponomaryov> bswartz: currently 1.8.x
15:32:42 <bswartz> so what is the point of the other sections?
15:32:56 <vponomaryov> bswartz: the same as for python3.x
15:32:57 <bswartz> for developers to check compatibility with future versions?
15:33:04 <vponomaryov> bswartz: switch to newest version
15:33:28 <tovchinnikova> bswartz, the main point is to have our tests fixed before using new versions
15:33:28 <bswartz> okay so I suspect the solution here is simple tovchinnikova
15:33:53 <bswartz> if the section name is py27dj110, then it should ensure that you really get 1.10 only and nothing later
15:34:06 <tovchinnikova> and compatibility of course
15:34:12 <bswartz> if what you want is *latest* then call the section py27dj-latest
15:34:38 <vponomaryov> bswartz: you are repeating my words from review )0
15:34:56 <tovchinnikova> bswartz, then we will have to rename gate job from latest to 110
15:35:24 <tovchinnikova> *when we have 111
15:35:25 <bswartz> I thought the gate job was running 1.8....
15:35:53 <bswartz> I think the gate should never run with latest -- we always need control of what the gate runs to avoid surprise breakage
15:35:56 <vponomaryov> tovchinnikova: it does not answer absence of ceiling
15:36:12 <bswartz> if developers want to run with latest on their own that's fine
15:36:22 <vponomaryov> tovchinnikova: you can keep name but use ceiling
15:36:46 <tovchinnikova> okay, let's use ceiling and keep the name 1.10
15:37:10 <tovchinnikova> thank you all for the discussion
15:37:16 <bswartz> awesome
15:37:21 <bswartz> anything else for today?
15:37:36 <bswartz> going once
15:37:36 <vponomaryov> yeah, don't forget to review manila UI!
15:37:40 <gouthamr> do we have the results of the vote?
15:37:46 <bswartz> oh
15:37:51 <bswartz> good point gouthamr
15:37:52 <ganso> gouthamr: +1!!!
15:38:29 <markstur_> is it too late to lobby for our favorite critters?
15:39:26 <bswartz> gorilla wins with 21% of the vote
15:39:35 <gouthamr> markstur_: depends on if it can win a fist fight with gorilla
15:40:00 <ganso> so manila gorilla it is then
15:40:00 <bswartz> second place was a tie between chinchilla, kangaroo, and venus fly trap with 12% each
15:40:05 <vponomaryov> bswartz: what is the percentage for second?
15:40:35 <vponomaryov> I suspect chinchilla would not be accepted anyway as very similar to mouse
15:40:47 <dustins> Any stats on Team Box Turtle?
15:40:56 <bswartz> dustins: 9%
15:41:05 <gouthamr> dustins: we tried.
15:41:09 <dustins> Better than expected :D
15:41:35 <bswartz> okay I think that's it for today
15:41:36 <markstur_> vponomaryov, if chinchilla is too similar to mouse, aren't gorillas just big monkeys?
15:41:52 <vponomaryov> markstur_: or shaggy bullies )0
15:41:54 <bswartz> I'll tell the foundation we want gorilla and we'll see if it takes
15:42:09 <bswartz> if it's taken*
15:42:11 <bswartz> thanks all
15:42:17 <markstur_> bswartz, tell them we want it to be a big one.  Not just some monkey.
15:42:28 <bswartz> #endmeeting