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