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