15:00:04 <bswartz> #startmeeting manila
15:00:04 <openstack> Meeting started Thu Nov 19 15:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:09 <openstack> The meeting name has been set to 'manila'
15:00:18 <bswartz> hello all
15:00:21 <xyang1> hi
15:00:22 <vponomaryov> hi
15:00:23 <u_glide1> hello
15:00:28 <markstur_> hi
15:00:44 <tbarron> hi
15:01:01 <ganso> hello
15:01:04 <bswartz> cknight ganso ameade: ping
15:01:20 <toabctl> hi
15:01:24 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:59 <bswartz> okay first thing I should note -- next thursday (Nov 26) is a holiday in the USA
15:02:08 <bswartz> I plan to cancel this meeting next week
15:03:03 <bswartz> you guys could hold a meeting without me but most of us USA-based people won't be there I expect
15:03:07 <cknight> Hi
15:03:16 <bswartz> #topic GB --> GiB
15:03:26 <bswartz> markstur_: you're up
15:03:35 <markstur_> rhagarty has a UI patch to change GB to GiB
15:03:57 <markstur_> I think this is correct. Just a head-up and check to see if anyone thinks otherwise.
15:04:04 <bswartz> +1
15:04:05 <markstur_> https://en.wikipedia.org/wiki/Gibibyte
15:04:19 <bswartz> GB is only used for disk drives -- most filesystems are measured in GiB
15:04:25 <vponomaryov> markstur_: I am not sure all drivers use GiB indeed
15:04:26 <bswartz> and GiB is less ambiguous
15:04:31 <markstur_> Cinder went thru the same thing.
15:04:31 <ganso> markstur_: +1
15:04:35 <markstur_> Yes less ambiguous
15:04:36 <tbarron> markstur_: +1
15:04:46 <markstur_> Just some people are used to seeing GB anyway.
15:05:09 <markstur_> We can probably move on if no one has concerns.
15:05:11 <tbarron> If they see GiB they'll figure it out.
15:05:19 <bswartz> so let's ask right now -- is anyone aware of drivers that use GB not GiB?
15:05:36 <vponomaryov> markstur_: Generic driver share with size eq 1 has real size about 960 Mb
15:05:46 <bswartz> I think we should simply consider that to be a bug if we find it
15:05:52 <tbarron> bswartz: +1
15:05:57 * gibi got a highlight for Gibibyte :)
15:06:00 <markstur_> vponomaryov, is that because it is using GB or just because of some overhead
15:06:21 <vponomaryov> markstur_: didn't dig up
15:06:24 <bswartz> I'm guessing overhead
15:06:28 <vponomaryov> markstur_: just observed on lab
15:06:36 <bswartz> most filesystems reserve 5% of blocks
15:06:50 <tbarron> in any case it would be weird for cinder to do GiB and manila to do GB
15:07:02 <bswartz> yes
15:07:29 <vponomaryov> so, if you all sure that Cinder does GiB too as all other manila share drivers, then ok, lets change it
15:07:31 <bswartz> all driver maintainers -- please investigate your drivers if you're not sure you're using GiB (2^30 bytes)
15:07:55 <bswartz> #topic OpenStack Manuals and Devref
15:08:04 <markstur_> https://wiki.openstack.org/wiki/Documentation/Migrate
15:08:04 <bswartz> markstur_: you again
15:08:07 <markstur_> Good news.
15:08:22 <markstur_> manuals will be RST instead of that XML docbook
15:08:41 <markstur_> I wanted to let vendors know because there is some config-ref work going on or todo
15:08:47 <markstur_> It'll be easier in RST
15:08:57 <markstur_> That wiki shows plan/progress.
15:09:10 <bswartz> markstur_: the docbook to RST migration has been planned for a while and it's a gradual process
15:09:13 <markstur_> Not sure when Manila config-ref will be done, but the plan is Mitaka
15:09:21 <tbarron> much earier to write RST IMO
15:09:37 <markstur_> bswartz, So are you saying it might not happen in Mitaka?
15:09:44 <bswartz> markstur_: how can they migrate the config-ref partially?
15:09:54 <bswartz> well I understood they were doing it 1 doc at a time
15:10:00 <xyang1> markstur_: the doc team will be doing the migration, right?
15:10:02 <bswartz> but each doc has to be converted all or nothing
15:10:21 <bswartz> We should certainly offer to help with the manila parts if they need help
15:11:25 <markstur_> Yes. Last I checked there wasn't much setup yet.  If the index is there it'll be easy for us to do our poart.
15:11:34 <markstur_> s/poart/part/
15:11:38 <bswartz> okay
15:11:46 <bswartz> anything else on the doc migration?
15:11:55 <markstur_> Next doc topic wasn't really migration.
15:12:06 <markstur_> It came up that our devref needs to cover old releases.
15:12:24 <bswartz> huh?
15:12:28 <markstur_> But that gets ugly.
15:12:39 <bswartz> what does that even mean?
15:12:44 <markstur_> For example, or 3par page needs to describe old version as well as latest
15:12:52 <markstur_> because people use the latest.
15:12:57 <cfouts> hi
15:12:58 <markstur_> Similar to our feature matrix
15:13:16 <markstur_> Eventually links to config-ref could solve most of that.
15:13:34 <bswartz> okay so driver config documentation should NOT be in the devref anymore
15:13:36 <markstur_> But currently one idea was to use subpages as needed to describe older versions
15:13:42 <bswartz> it should be moved to the config ref
15:13:55 <toabctl> markstur_: feature matrix doesn't describe an old version. it describes the current status and when things were  introduced.
15:14:14 <bswartz> and the config ref can document different versions of the driver if it needs to
15:14:19 <markstur_> toabctl, Sure. That is different.
15:14:53 <markstur_> We still don't have driver doc for kilo w/o the devref
15:15:04 <markstur_> Just the bare RST files intree
15:15:43 <bswartz> markstur_: can't that information be migrated to the config guide?
15:15:59 <markstur_> bswartz, The config-ref in openstack manuals is versioned
15:16:05 <markstur_> So we have one for Libert, Mitaka
15:16:10 <markstur_> still nothing for Kilo
15:16:36 <markstur_> Perhaps our current pages could maintain that and use links where possible.
15:16:37 <bswartz> markstur: but they don't actually have branches, they just cut releases out of master
15:17:06 <markstur_> The think is you can access an on-line document for a version
15:17:13 <markstur_> s/think/thing/
15:17:45 <markstur_> I'm just wondering if we can share an approach as we deal with our devref pages
15:17:55 <markstur_> Not sure we want to solve that today
15:17:57 <bswartz> my preference is that docs for drivers move out of the tree, whether for the current version or older versions
15:18:34 <bswartz> eventually this problem will solve itself as versions older than liberty become obsolete
15:18:42 <markstur_> Yes
15:18:58 <markstur_> We could just refer the the cgit kilo source
15:18:58 <bswartz> if you need special docs for Kilo, I propose adding them as a historical note in the current version of your config-ref
15:19:15 <markstur_> +1
15:19:29 <markstur_> I guess if we add a little history and not too much detail
15:19:51 <markstur_> that is the approach we settled on with the HP->HPE rebranding
15:19:58 <bswartz> and there are plenty of other options, including wiki pages or github.io sites (which is what NetApp does)
15:20:47 <markstur_> OK. I don't think we need to discuss it more.  We can maybe bring it back up if there is a push to clean-up and get consistency.
15:20:52 <bswartz> okay
15:21:00 <bswartz> #topic Midcycle Meetup Date
15:21:34 <bswartz> so the cinder team has picked the date for their midcycle meetup (first week of M-3, Jan 26-29)
15:22:06 <bswartz> more interestingly, they've picked the location for their meetup as the NetApp office here in RTP, which is where we've attemped to hold previous manila midcycle meetups
15:22:59 <bswartz> we always try to not conflict with the cinder meetup due to the extra travel is causes for some of us, but there is an opportunity to maybe get both meetups in 1 trip this cycle
15:23:29 <cknight> bswartz: +1
15:23:31 <bswartz> I wonder if anyone would be interested in a physical midcycle meetup for Manila this cycle or if we should keep doing virtual ones
15:24:21 <cknight> paging xyang1.  wanna spend a week in RTP?
15:24:25 <toabctl> for me, only virtual is possible
15:24:26 <bswartz> I'm also cautious because I know that it's easy to get burned out by the midcycle meetups -- they take a lot of energy and 2 back to back could be terrible
15:24:52 <xyang1> cknight: I'm planning to go to the cinder one
15:25:24 <cknight> xyang1: so you could stay a couple more days for manila?
15:25:28 <bswartz> xyang1: if we schedule the manila one adjacent to the cinder one would that make you want to stay longer?
15:26:05 <xyang1> cknight: bswartz how are you planning for this?  staying for two weeks will be tough for me
15:26:08 <bswartz> if xyang1 and I are the only ones planning to go to both meetups then maybe this matter less
15:26:26 <bswartz> xyang1: we don't have a plan yet, I'm soliciting input
15:26:50 <tbarron> I'll go to both :-)
15:27:03 <markstur_> Do you know which days Cinder will take?
15:27:09 <bswartz> if you're interested, we can try to pick an adjacent time for the manila meetup, if not, we'll do something else
15:27:17 <markstur_> tbarron, is that a long commute for you?
15:27:21 <tbarron> Tuesday through Thursdady, Friday optional sprint.
15:27:21 <xyang1> 1/26 to 29
15:27:28 <bswartz> markstur_: they're saying 1/26-1/29 (tuesday-friday)
15:27:32 <tbarron> markstur_: about 45 minutes
15:27:51 <tbarron> markstur_: when my truck works.
15:28:42 <bswartz> so assuming we don't try to combine the meetups, then the question is, should we aim for a week before or a week after, or should we aim for a larger gap?
15:29:29 <bswartz> that last week of january is the first week of M-3, so getting any later than that means it will be too late to influence what happens during Mitaka
15:29:48 <bswartz> however earlier than that means the M-2 milestone date or getting close to the winter holidays
15:30:11 <bswartz> during Liberty we did hold the meetup the same week as the L-2 milestone and that turned out okay
15:30:38 <markstur_> Sounds to me like the week before would be a good pick
15:30:55 <markstur_> There might be a monday holiday in the US
15:30:59 * bswartz is thinking he might need to do an online unscientific poll like DuncanT did
15:31:20 <xyang1> markstur_: what holiday
15:31:42 <markstur_> MLK day is Jan 18.
15:31:52 <xyang1> ok
15:32:01 <bswartz> okay that would affect us if we aim for the week before cinder's meetup
15:32:14 <bswartz> however in teh past we've just done 2 days (tue-wed or wed-thu)
15:32:18 <markstur_> only Monday though.  I don't think that week would be too bad
15:32:39 <bswartz> okay I think I'll try to setup an poll and send it to the mail list
15:32:53 <bswartz> all of you read the openstack-dev mail list, right?
15:33:08 <markstur_> of course
15:33:09 <xyang1> yes
15:33:11 <bswartz> heh
15:33:15 <bswartz> okay let's move on
15:33:21 <bswartz> #topic Deadlines for features
15:33:22 <markstur_> when the word manila appears in it
15:33:43 <vponomaryov> for me it is not enough criterion ))
15:33:53 <vponomaryov> I do not receive some mails
15:34:11 <gouthamr> bswartz: on this topic.. could I get an ETA on when we want the share replication feature would be merged.
15:34:23 <gouthamr> s/would/to
15:35:01 <bswartz> so we discussed before Tokyo that we need to specify an earlier deadline for "large" features to avoid the situation we had during the liberty feature freeze
15:35:12 <bswartz> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
15:35:32 <bswartz> as you can see from the schedule, feature freeze will be March 3 this cycle
15:35:51 <bswartz> so as usual we'll have a feature proposal freeze 2 weeks earlier on Feb 18
15:36:14 <bswartz> however for big things, 2 weeks is not enough to complete the review cycles and get things merged
15:36:59 <bswartz> I propose that for features that we deem "large" we require them to be proposed by the M-2 date (6 weeks before feature freeze)
15:37:32 <xyang1> bswartz: how do you define "large"?
15:37:34 <bswartz> by proposed I mean a WIP patch in gerrit
15:37:40 <bswartz> xyang1: I'll get to that next
15:37:43 <xyang1> bswartz: ok
15:37:48 <bswartz> first I'd like to get some agreement on the date
15:38:01 <bswartz> is 6 weeks not enough? could we live with less?
15:38:32 <markstur_> we could decide if there are exceptions during midcycle meetup
15:38:34 <bswartz> the point of an earlier deadline is that large new features typically require multiple review/fix cycles
15:38:35 <xyang1> M-2 seems reasonable
15:39:00 <bswartz> yes we can always make exceptions, but the goal here is to set expectations so nobody is disappointed their feature didn't get merged
15:39:08 <cknight> bswartz: sounds good
15:39:11 <markstur_> +1
15:39:14 <bswartz> and it should also be pointed out that even features which do make the deadline could still not get merged if we're unhappy with them
15:39:18 <xyang1> bswartz: +1
15:39:37 <ganso> bswartz: +1
15:39:58 <bswartz> ^ that should be obvious but sometime managers act surprised by that
15:40:33 <bswartz> okay so then we need to figure out how we define large features
15:41:11 <JayXu> the number of code lines?
15:41:16 <bswartz> my initial instinct was to go by lines of code -- for example, if a patch adds 500 more lines than it removes, and it's not purely a driver change, we consider it "large"
15:41:40 <bswartz> such a rule would except renames and straightforward refactor patches from being considered large
15:41:49 <bswartz> but cknight had a better idea (IMO)
15:42:53 <bswartz> we could deem a feature "large" if it affects 3 or more of the following: DB schema, REST API, RPC layer, scheduler, or the manager
15:43:45 <bswartz> thus even relatively small changes that touch lots of Manila would be considered large, but huge change limited to 1 part of the code would not
15:44:27 <bswartz> the point of this designation is to find changes that are likely to require lots of testing and lots of round trips between the develops and the reviewers
15:45:11 <bswartz> IMO large refactor patches typically take a long time to review, but after your review them you typically make a few changes and you're done, thus we don't need an earlier deadline for them
15:45:56 <bswartz> whereas brand new features usually require significant changes after testing and reviewing even if the feature is not that large
15:46:18 <bswartz> does anyone fine the later definition better than going just by lines of code?
15:46:46 <JayXu> +1, make more sense
15:46:48 <sghatty_> bswartz +1.
15:46:50 <bswartz> I think lines of code is easier to enforce, but also easier to game
15:46:50 <vponomaryov> combne both?
15:46:59 <ganso> vponomaryov: +1
15:47:03 <xyang1> bswartz: if we get lots of huge patches submitted last minute, that will be tough too
15:47:26 <xyang1> vponomaryov: +1
15:47:27 <bswartz> xyang1: everything will be subject to the 2 week feature proposal freeze deadline
15:47:36 <bswartz> so at a minimum we'll have 2 whole weeks
15:48:00 <bswartz> and if we get the "large" stuff handled earlier then it shouldn't be so bad right before feature freeze
15:48:16 <bswartz> also I have one more proposal regarding new drivers
15:48:46 <markstur_> is the 2 week feature proposal freeze documented somewhere?
15:49:11 <bswartz> markstur_: it used to be documented on the official schedule, but it seems to be gone in Mitaka
15:49:12 <tbarron> what about vponomaryov and xyang1 proposal to commbine both: if either > 500 new lines or 3 or more of the areas
15:49:46 <vponomaryov> tbarron: also, 500+ lines not related to tests
15:49:49 <bswartz> markstur_: I'll make an ML announcmeent containing all of this info
15:49:55 <tbarron> vponomaryov: +1
15:49:56 <ganso> vponomaryov: +1
15:50:02 <xyang1> vponomaryov: good idea
15:50:04 <cknight> vponomaryov: +1  tests add lots of lines!
15:50:19 <JayXu> vponomaryov +1
15:50:20 <cknight> bswartz: the deadlines should still be posted somewhere
15:50:23 <xyang1> vponomaryov: we don't want to discouraged people to add tests
15:50:25 <tbarron> nah, that's what ddt is for :-)
15:50:30 <bswartz> so just to be clear, my suggestion is we take the added lines and subtract the removed lines and compare that number to 500
15:50:40 <bswartz> I'm fine with excluding tests from that computation
15:51:12 <cknight> bswartz: sounds good.  that makes refactors look smaller, and they're easier to review since all the functional tests should be passing
15:51:59 <markstur_> Sounds good. If we get too many exception requests we can tune our criteria next time.
15:52:12 <bswartz> and again we're trying to come up with a numerical definition to help people understand what we're aiming for, but we don't want to override human judgmeent
15:52:21 <bswartz> markstur_: exactly
15:52:32 <bswartz> we can make exceptions in either direction if needed
15:52:52 <bswartz> okay so it sounds like we're in agreement on these 2 things
15:53:01 <bswartz> so the last topic was about new drivers
15:53:19 <bswartz> my stance has been that drivers are okay to submit right up until feature freeze
15:53:51 <bswartz> however it's true that reviewing a new driver is a LOT of code to read, and we don't want to encourage driver developers to submit right on Feb 18th
15:54:24 <bswartz> so how do people feel about 1 week earlier deadline for both drivers, and driver refactor patches that are comparable in size to a whole new driver?
15:54:40 <bswartz> Feb 11th would be the driver deadline -- to give reviewers 1 extra week
15:54:59 <bswartz> this topic came up in the channel yesterday when redhat was asking about it
15:55:00 <vponomaryov> some driver refactors comparable to two new drivers ))
15:55:11 <bswartz> vponomaryov: lol
15:55:40 <bswartz> worst case, when reviewing a driver refactor, just ignore the old code and treat it like a new driver
15:56:24 <xyang1> vponomaryov: an earlier deadline for two driver in 1?:)
15:57:26 <bswartz> so this last one is mostly a courtesy to the reviewers, ideally we wouldn't need a special deadline, but if it help project managers plan better then I think we should make it official
15:57:59 <bswartz> any opposed to Feb 11th deadline for new drivers and driver refactors?
15:58:22 <xyang1> bswartz: so the big feature deadline is only for common code change, driver change is not restricted by that?
15:58:39 <vponomaryov> bswartz: do we consider early merge of driver with not complete set of features with folowing extend?
15:58:42 <bswartz> xyang1: yes the theory is that driver code is except from the "large" feature rule
15:58:54 <csaba> bswartz: so then what is considered to be a "driver refactor"?
15:59:00 <bswartz> because driver changes are inherently less risky, although they still tax the core reviewer team
15:59:24 <vponomaryov> csaba: just look at latest changes to EMC drivers
15:59:30 <JayXu> :)
15:59:36 <vponomaryov> csaba: look at amount of patch-sets
15:59:40 <JayXu> a bad example
15:59:46 <cknight> csaba: Your patches in Liberty were a driver refactor.
15:59:48 <vponomaryov> csaba: and, attention, number of code lines
15:59:57 <bswartz> csaba: that's a good question, I think any change that alters a large fraction of a driver
16:00:18 <cknight> csaba: So you can't refactor again in Mitaka ;-)
16:00:28 <ganso> time check: 0 minutes left... no time for my topic :(
16:00:38 <csaba> vponomaryov, cknight: you are all right but so far the goal was to pin down objective criteria
16:00:47 <bswartz> yes, I think the changes to the glusterfs-native driver at the end of liberty would have counted as a refactor, so do that kind of stuff earlier this cycle
16:00:53 <bswartz> oh crud I lost track of time
16:01:11 <bswartz> sorry ganso we can continue in the manila channel
16:01:11 <gouthamr> ganso: I'm taking my questions to the manila channel right now :)
16:01:20 <bswartz> #endmeeting