15:00:35 #startmeeting manila 15:00:35 Meeting started Thu Mar 5 15:00:35 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:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:40 The meeting name has been set to 'manila' 15:00:44 Hi 15:00:46 hello all! 15:00:47 hi 15:00:47 o/ 15:00:51 hi 15:00:51 Hi all 15:01:06 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:01:23 hi 15:01:25 hi 15:01:28 hi 15:01:47 we're almost done with a bunch of stuff 15:01:50 hi 15:02:08 looks like dev status is first thing on the agenda today though 15:02:11 #topic dev status 15:02:23 Dev status: 15:02:27 1) Nova network plugin 15:02:31 BP: #link https://blueprints.launchpad.net/manila/+spec/nova-network-plugin 15:02:36 gerrit: #link https://review.openstack.org/160393 15:02:41 status: ready for review 15:02:45 2) RO access in Generic Driver 15:02:49 BP: #link https://blueprints.launchpad.net/manila/+spec/generic-driver-ro-access 15:02:52 gerrit: #link https://review.openstack.org/161176 15:02:56 3) Multiple export locations 15:03:00 BP: #link https://blueprints.launchpad.net/manila/+spec/multiple-export-locations 15:03:07 gerrit: #link https://review.openstack.org/159927 15:03:11 4) Private share types 15:03:15 BP: #link https://blueprints.launchpad.net/manila/+spec/private-share-types 15:03:17 gerrit: #link https://review.openstack.org/157794 15:03:25 that's the main 15:03:41 cool 15:03:47 everything is ready for review 15:03:55 I gues 3 is interesting for lots of driver maintainers 15:03:57 hi 15:04:02 I think we've discussed all the above items before 15:04:15 yeah #3 is interesting 15:04:37 if any driver developers want to slip in a patch to support it, you've got 2 weeks (if you can do it in a small patch) 15:05:23 vponomaryov1: you forgot to mention manage/unmanage, which is still pending 15:05:45 the code for that is in good shape, but we need to add generic driver support so we can exercise/test the code 15:05:45 bswartz: it was mentioned several times before =) 15:05:52 bswartz: long playing one 15:06:01 yeah I just want eveyont to be aware that it's hanging out and still receiving attention 15:06:22 okay if there's no questions on that then 15:06:26 #topic K-3 deadlines 15:06:52 so this shouldn't be news to anyone, but TODAY is the K-3 feature proposal freeze 15:07:15 it looks like almost everyone has been diligent about getting their BPs completed 15:07:27 thank you for striving to meet the deadline 15:07:55 #link https://launchpad.net/manila/+milestone/kilo-3 15:08:27 all the BPs look good, with the exception of nileshb's 15:08:28 nileshb: ping 15:08:43 hmm he's not here it seems 15:09:01 he indicated to me before that he was fine with the ganesha work slipping to liberty 15:09:31 and that's done now 15:09:44 so the BPs are in good shape, the bugs are not 15:10:08 we'll need to turn our focus to bugs in a week or two 15:10:17 right now we have 2 weeks until feature freeze 15:10:39 reviewer should prioritize reviews for BPs targeted at K-3 15:10:45 we want to merge everything on that list 15:10:58 if other stuff comes in, review it at lowest priority 15:11:11 if big new feature patchsets show up, I will -2 them 15:11:52 small patchsets to add driver support for multiple export locations or manage/unmanage are okay, but they need to be small 15:12:29 any questions about these deadlines? 15:12:50 right now I'm planning on granting no feature freeeze exceptions -- I think we're in good shape on everything 15:13:21 wow you guys are easy 15:13:30 * bswartz wonders if he's talking to himself... 15:13:43 #topic backslashes on CIFS export paths 15:13:44 *lol* 15:13:44 we're listening 15:14:08 bswartz: still listening :) 15:14:26 so a question came up last week about what kind of slashes to use for CIFS share export paths 15:14:40 most of the existing drivers use forward slashes, which doesn't make a lot of sense 15:15:06 HP even submitted a patch to change from back slashes to forward slashes, which is what brought this up 15:15:07 / is handy on linux mount -t cifs // 15:15:19 bswartz: let driver decide it, and, after multiple export locations implementation - even more 15:15:23 I see no reason to use forward slashes 15:15:39 bswartz: allowing both or some one 15:16:01 markstur_: that's the only advantage I can think of for forward slashes, but I HIGHLY doubt that any real users will use CIFS+Linux together 15:16:16 I expect CIFS will be used by Windows users for the most part 15:16:21 Linux users are likely to stick with NFS 15:16:40 thus we should be providing paths that are Windows friendly 15:16:56 bswartz: both, using multiple export locations =) 15:17:05 vponomaryov1: +1 15:17:11 //share/path can't be copy/pasted into a windows command line 15:17:41 vponomaryov1: the purpose of multiple export locations is to provide different actual paths, not just different formats for the same path 15:18:00 Both is handy, but maybe not as clean as just the one if there is any confusion about a "first one" 15:18:02 it may be that \\10.0.0.1\my_share and \\10.0.0.2\my_share are actually the same share 15:18:40 I know that linux command line tools can deal with backslashes with appropriate quoting/escaping 15:19:28 anyways, ultimately it is up to the driver to return these paths, but I think the manila community should agree on a convention that everyone should stick to 15:19:51 and I propose that backslashes should be preferred when displaying CIFS export locations 15:20:01 bswartz: i agree 15:20:11 bswartz: +1 15:20:18 +1 15:20:32 I plan to submit a patch to make changes to existing drivers, but with some vendor drivers might do weird things, so I might not catch all the cases 15:20:49 +1 15:20:50 bswartz: in kilo? 15:20:54 yes 15:21:00 ideally before Feature Freeze 15:21:30 I consider it a bug that our CIFS paths are not windows-friendly, but because it's a user-visible change it should go in before FF 15:22:01 initial investigations indicate that changing forward to backslashes won't cause any problems in the API layer or DB layer 15:22:13 so this should be an easy change 15:22:39 does it makes sense to have manager or driver.py flip what is returned by drivers? 15:22:58 markstur_: I considered that, and I can see problems 15:23:00 so you don't have to change them all 15:23:09 I would rather that the drivers just return the right thing 15:23:25 agree. just asking 15:24:10 it's a really small change, as you demonstrated in https://review.openstack.org/#/c/161031/ 15:24:25 so close to a commit 15:24:41 do we have xyang2 here by any chance? 15:24:55 markstur_: :-) 15:24:59 markstur_: +1 15:25:00 bswartz: hi 15:25:13 nvm bswartz +1 15:25:14 xyang2: did you have an opinion on this? 15:25:39 bswartz: sorry I haven't completed followed. the backslash thing? 15:25:57 yeah we're trying to agree that all cifs share export paths should have backslashes rather than forward 15:26:02 do you see any problems with that? 15:26:18 bswartz: it seems ok, we just need to test driver after the change 15:26:30 yeah 15:26:36 expect a patchset from me soon 15:26:40 ok 15:26:41 I'll try to fix all the breakage I find 15:26:52 but extra eyes from driver maintainers will be good 15:27:19 it'll be good to get that consistent look and even better when we auto-mount 15:27:59 #agreed cifs export locations returned from drivers should have backslashes only, ben will submit patch to change existing drivers 15:28:06 #topic open discussion 15:28:34 so just a reminder: daylight savings time is coming this weekend, so people in the US will see this meeting move 1 hour later on their calendars 15:28:56 next week it will be 8AM Pacific / 11AM Eastern 15:29:13 it's still 1500 UTC for non-US people 15:29:27 wooo hoo 15:29:34 that should be nice for the west coast people especially 15:29:54 u_glide: did you want to talk about horizon at all today? 15:30:04 anyone else have a topic -- we'd got plenty of time 15:30:06 yes 15:30:40 Recently I have proposed to make some investigation related to horizon dashboards. 15:31:10 Does anybody familiar with this topic? 15:31:26 a little 15:31:41 example of external dashboard https://github.com/openstack/sahara-dashboard/tree/stable/icehouse 15:32:13 u_glide: why only icehouse? did they abandon that approach in juno: 15:32:13 ? 15:32:36 No, they integrated in core since kilo 15:33:01 or juno 15:33:14 I don't know that 15:33:19 is the mechanism used by them still the same? 15:33:19 :) 15:33:50 no, after integration all code was moved to openstack_dashboard 15:34:15 which code was moved? the sahara code or the horizon code? 15:34:58 sahara code was moved in horizon default dashboard 15:35:19 https://github.com/openstack/horizon/tree/master/openstack_dashboard 15:35:28 right but how were they getting their dashboard code to load inside of horizon prior to the move? 15:36:06 http://docs.openstack.org/developer/sahara/horizon/installation.guide.html 15:36:51 our horizon code has a bunch of changes to the core horizon modules to link in our pages 15:37:03 vponomaryov1: have you taken a look at this before? 15:37:16 bswartz: no, see first time 15:37:24 bswartz: probably we can reduce this changes 15:37:32 okay well I'm hopefully this kind of approach might work 15:37:55 it would allow us to not need to maintain a fork of horizon at the very least 15:38:11 and possibly it would allow us to move our horizon integration into a contrib dir 15:38:17 can you provide a link to our current fork? 15:38:39 https://github.com/NetApp/horizon/tree/manila_juno 15:38:55 we put it on the netapp github because we couldn't find a better home for it 15:39:34 I would be MUCH happier to have this under gerrit change control 15:40:09 we intend to update this fork to be kilo-compatible 15:40:34 bswartz: >> and possibly it would allow us to move our horizon integration into a contrib dir - I think it's bad idea in this case 15:40:35 if we can do something better though, such as u_glide's suggestion, I'm open to that approach 15:40:49 u_glide: you propose a whole new repo? 15:41:10 yes, because this dashboard should have own tests 15:41:34 and CI jobs 15:41:45 like horizon compatibility tests 15:42:44 hmm well that doesn't sound like a kilo thing -- probably liberty 15:43:02 is our horizon broken lately or just on my devstacks? 15:43:06 although if it's separate, we could start with kilo 15:43:10 yes, it's big amount of work 15:43:17 markstur_: it will work if you're running juno 15:43:18 markstur_: it is juno - compatible only right now 15:43:33 markstur_: if you try with kilo, expect big problems 15:43:42 was good until recently 15:43:45 ok 15:43:49 the plan is to fix our horizon branch *after* the horizon feature freeze in 2 weeks 15:44:41 actually: this one is "nice to have" 15:44:42 markstur_: maybe volume_type->share_type rename broke things? 15:44:46 but not a must 15:45:04 we can support latest manila based on "juno horizon" 15:45:19 bswartz, maybe 15:45:52 there are 4 things working together here: 15:45:56 manila version 15:46:03 manila client version 15:46:06 horizon version 15:46:12 and version of horizon-manila fork 15:46:33 actually I guess the horizon version doesn't count if you're running the fork 15:46:42 so 3 things 15:46:50 right 15:47:10 if you get the manila client version to match the horizon-manila fork version you can make it work 15:47:28 the first thing to fix in the fork is to support modern manila clients 15:47:46 and new features in general 15:47:46 then to support changed features from during kilo 15:48:35 okay so expect to hear more about horizon after the feature freeze 15:48:50 I look forward to an investigation of better ways to maintain our dashboard 15:49:00 u_glide: :-) 15:49:19 okay anything else? 15:49:30 bswartz: ok 15:49:43 I think that's it for today 15:49:49 thanks all 15:50:04 thanks 15:50:34 #endmeeting