15:04:30 <bswartz> #startmeeting manila
15:04:31 <openstack> Meeting started Thu Dec 18 15:04:30 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:35 <openstack> The meeting name has been set to 'manila'
15:04:43 <bswartz> hey guys sorry I spaced out
15:04:45 <cknight> Hi
15:04:48 <xyang1> hi
15:04:50 <rushil> hi
15:04:52 <csaba> hi
15:04:58 <bswartz> was debugging a script
15:05:03 <vponomaryov> hello
15:05:05 <jasonsb> hi
15:05:10 <diemt> hi
15:05:13 <tbarron> hi
15:05:13 <rraja> hi
15:05:18 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:05:22 <vvechkanov> hi
15:05:50 <bswartz> there's several things to dicuss today
15:05:55 <bswartz> #topic dev status
15:05:58 <ganso> hi
15:06:02 <bswartz> we'll start with last weeks status update
15:06:02 <vponomaryov> dev status:
15:06:08 <vponomaryov> 1) Share Drivers are able to make its own networking stuff now
15:06:14 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/network-helper
15:06:17 <vponomaryov> commit: #link https://github.com/openstack/manila/commit/36db3f39
15:06:25 <vponomaryov> 2) Share driver parent class now implements "modes" for Share drivers
15:06:30 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/driver-modes
15:06:36 <vponomaryov> commit: #link https://github.com/openstack/manila/commit/28f311c9
15:06:42 <vponomaryov> 3) Split service_instance module to compute and networking
15:06:46 <vponomaryov> gerrit: #link https://review.openstack.org/#/c/141760/
15:06:49 <vponomaryov> status: ready for review
15:06:56 <vponomaryov> that's the main
15:07:09 <bswartz> thanks vponomaryov
15:07:41 <bswartz> so 1 and 2 merged just in the last day
15:08:17 <bswartz> #topic Kilo-1 milestone review
15:09:09 <bswartz> so several of the BPs targetted for K-1 did not merge :-(
15:09:41 <bswartz> I think it's probably my fault for not giving people enough warning
15:09:53 <bswartz> and not being as proactive on reviews as I could have been
15:10:04 <bswartz> it's not a big deal to miss k-1 because we still have 2 more dev milestones
15:10:14 <jasonsb> #link https://blueprints.launchpad.net/manila/kilo
15:10:29 <bswartz> however we should try to be better about getting stuff reviewed/merged earlier
15:10:39 <csaba> bswartz: what is the actual deadline to hour precision?
15:11:01 <csaba> or nanosec :)
15:11:06 <bswartz> because if this happens for k-3 we'll be forced to choose between granting a FFE or letting a feature slip out of kilo
15:11:07 <vponomaryov> csaba: 50 min left
15:11:11 <vponomaryov> 49 =)
15:11:36 <bswartz> csaba: 1600 UTC -- and your change will be in check for probably an hour or more
15:11:50 <bswartz> unless the gate is suddenly faster than yesterday
15:11:54 <vponomaryov> bswartz: 20 min
15:12:12 <bswartz> sorry I meant the check jobs are suddenly faster
15:12:22 <vponomaryov> 20 min for check jobs left
15:12:32 <vponomaryov> + 15 for merge set of gates
15:12:36 <bswartz> I won't press +2A unless it passes check job
15:12:50 <bswartz> csaba: don't worry about it, we can still merge it today
15:13:07 <csaba> bswartz: of course, cool
15:13:09 <bswartz> maybe you'll have the honor of the first merge in K-2
15:13:13 <jasonsb> better link #link https://launchpad.net/manila/+milestone/kilo-1
15:13:23 <bswartz> jasonb: thanks
15:14:00 <bswartz> so after this meeting I'm getting together with ttx and he will press the button, and everything not done will push to K-2
15:14:36 <bswartz> any other question about k-1?
15:15:08 <bswartz> #topic Kilo-2 planning
15:15:14 <bswartz> #link https://launchpad.net/manila/+milestone/kilo-2
15:15:21 <bswartz> okay so here's what we have
15:15:33 <bswartz> the stuff that's not done from K-1 will be joining this list soon
15:16:25 <bswartz> we'll have 7 weeks for k-2, but part of that time is holidays for most people
15:16:42 <bswartz> k-2 will be open for new features and drivers
15:16:48 <esheffield> eld
15:17:00 <bswartz> I'm hoping we will wrap up the rest of the stuff we talked about in paris
15:17:18 <bswartz> and get the rest of the drivers merged, so K-3 can be relatively quiet
15:17:36 <vponomaryov> bswartz: quiet? not sure
15:17:41 <bswartz> anyways if you're working on anything you hope to merge, please make sure it's on the list
15:17:50 <bswartz> vponomaryov: it's just a hope
15:18:00 <bswartz> we'll see what actually happen :-)
15:18:06 <bswartz> happens*
15:18:19 <vponomaryov> bswartz: same as today =)
15:18:19 <jasonsb> can i get hds driver on list?
15:18:28 <bswartz> there's one other thing I want to focus on in K-2, which is functional tests
15:18:48 <bswartz> jasonsb: send me a link
15:18:49 <vponomaryov> bswartz: manila or client?
15:18:58 <bswartz> vponomaryov: manila functional tests
15:19:02 <jasonsb> ok i'll make and send
15:19:18 <vponomaryov> bswartz: "manila functional tests" - tempest tests
15:19:37 <bswartz> once all the driver-impacting changes are in, we should turn our attention to making our tests more stable, and making them actually gate changes
15:20:02 <bswartz> right now it's possible to pass jenkins even if tempest fails, and in fact tempest fails somewhat regularly
15:20:16 <vponomaryov> bswartz: it is not related to manila directly
15:20:18 <bswartz> usually it's timeout problems, but that's not acceptable
15:20:27 <vponomaryov> bswartz: some errors like VM has not been started, etc
15:20:38 <vponomaryov> bswartz: it will be more stable on third-party CI
15:20:40 <bswartz> if there are tests that can't pass reliably, we need to remove those tests and replace them with tests that do pass reliably
15:21:11 <bswartz> also I'd like to see tests that exercise more functionality
15:21:13 <vponomaryov> bswartz: no specific - VMs for Generic driver - main reason of fails
15:21:29 <bswartz> right now there's no verification that the shares created are even mountable
15:21:55 <vponomaryov> this not functional
15:22:07 <vponomaryov> it is scenario will be
15:22:14 <bswartz> perhaps
15:22:36 <bswartz> but even so, then we need scenario tests to be automated and made part of the gate
15:22:43 <vponomaryov> agree
15:23:16 <bswartz> testing needs to gradually get better -- I'm not sure where we will get by K-2 but I want to set the goal where we want to be
15:23:42 <bswartz> which is full end-to-end testing of drivers
15:24:24 <bswartz> okay
15:24:32 <bswartz> #topic NetApp cDOT driver refactoring
15:24:38 <cknight> #link:  https://blueprints.launchpad.net/manila/+spec/netapp-manila-cdot-driver-refactoring
15:24:39 <bswartz> cknight: you're up
15:24:47 <cknight> We recently refactored the NetApp Data ONTAP drivers in Cinder.
15:24:56 <cknight> The result is a four-layer driver (interface, library, client, API) with much shorter files for easier maintenance and readability and a fair bit of code sharing with the 7-mode driver.
15:25:04 <cknight> We are planning to do the same thing for Manila.
15:25:12 <cknight> The goals and work items are all in the blueprint.
15:25:21 <cknight> This work should be done early in the new year, so it would be good to know of any significant near-term changes planned in the Manila cluster-mode driver.
15:25:46 <cknight> If you want to see what it will look like, just look in Cinder now.
15:25:51 <cknight> Any questions?
15:26:11 <vponomaryov> cknight: what will be first this one or support of single driver mode?
15:26:27 <vponomaryov> how is it planned to be?
15:26:29 <bswartz> cknight: AFAIK there's only one open patchset which affects the netapp driver
15:26:41 <cknight> vponomaryov: good question.  Is single-driver mode ready to go in?
15:27:25 <vponomaryov> cknight: interface is merged, single SVM for cdot is unassigned task
15:27:37 <bswartz> vponomaryov: I think people on my team will be making the changes to the netapp driver
15:27:41 <bswartz> you don't need to worry about that
15:27:42 <vponomaryov> bswartz said NetApp team will work on it
15:27:57 <cknight> vponomaryov: yes, we'd like to do that immediately after the refactoring.
15:28:07 <vponomaryov> got it
15:28:13 <bswartz> the only thing cknight needs to be aware of is https://review.openstack.org/#/c/138689/
15:28:14 <cknight> bswartz: you are referring to the driver extension mechanism?
15:28:20 <bswartz> and any other change which affects all the drivers
15:28:25 <bswartz> cknight yes
15:28:45 <cknight> bswartz: I looked at it, and it should be straightforward to work with
15:28:53 <bswartz> okay
15:28:55 <bswartz> thanks cknight
15:29:07 <bswartz> #topic Holidays
15:29:30 <bswartz> so many of us have holidays coming up
15:29:37 <bswartz> unfortunately not all at the same time
15:29:50 <bswartz> I'm sure it will be harder to reach people for the next 2-3 weeks
15:30:03 <bswartz> and these meetings happen to fall right on the holidays here in the US
15:30:26 <bswartz> so I plan to cancel the next 2 meetings and plan to meet back up on Jan 8 2015
15:30:59 <vponomaryov> wow
15:31:21 <bswartz> I hope you guys enjoy your holidays and take some time off
15:31:46 <bswartz> I'll still be on IRC most of the next week and you can grab me for code reviews, etc
15:32:29 <bswartz> #topic Syetem services
15:32:34 <bswartz> csaba: go ahead
15:33:02 <csaba> this came up in context of ganesha, but the problem is generic
15:33:35 <csaba> ie. in ganesha, there is a service to manage for the ganesha nfsd
15:33:44 <csaba> and I observed interesting things
15:34:08 <csaba> nilesh, for gpfs, set up the share for /sbin/service
15:34:17 <bswartz> csaba: what exactly do you mean by "service"
15:34:19 <csaba> *share filter
15:34:25 <csaba> service command
15:34:40 <vponomaryov> you mean app within host?
15:34:54 <csaba> so nilesh choice was to restart ganesha with "service <service-name> restart'
15:34:55 <bswartz> you mean a systemd/upstart service?
15:34:59 <csaba> yep
15:35:02 <bswartz> ok
15:35:08 <csaba> or whatever init system controlled service
15:35:35 <csaba> now in ubuntu I found service is /usr/sbin/service ...
15:35:48 <bswartz> yes that's true
15:35:56 <csaba> so to make that code work on ubuntu, admin has to hack into share filters
15:36:24 <csaba> and beyond that, we can't expect that system services are managed by service(8)
15:36:48 <csaba> because 1) with systemd prevalence it might be not present
15:37:06 <bswartz> csaba: it sounds like the driver needs to autodetect what's it's running on and behave differently as a result
15:37:16 <csaba> 2) in more embedded-ish setup like a service vm there might be some custom mininal init system
15:37:23 <bswartz> or else there needs to be a config option for the admin to modify the behavior as needed
15:38:12 <csaba> bswartz: however, the question is so much general tthat I could imagine a common solution for whole openstack ecosystem
15:38:16 <nileshb> csaba, I understand the problem, its the filter that needs to be managed dynamically changed
15:38:48 <bswartz> I'm not sure what you mean by filter
15:38:57 <nileshb> the share filters
15:38:57 <bswartz> you mean the m-sch filters?
15:39:13 <csaba> nileshb: I think your choice is OK ATM, I was just wondering how it could be better with a general approach
15:39:30 <vponomaryov> bswartz: https://github.com/openstack/manila/blob/master/etc/manila/rootwrap.d/share.filters
15:39:43 <bswartz> you mean the rootwrap...
15:40:02 <nileshb> my choice is fine, but it may not work on all the systems
15:40:06 <bswartz> can't wildcards be used?
15:40:14 <csaba> I don't mean to start a new project, but at least I could imagine some oslo.* lib to address this... transparent system service management
15:40:19 <bswartz> {/usr,}/bin/service ?
15:40:35 <bswartz> {/usr,}/sbin/service
15:40:52 <tbarron> there's a general dependency of rootwrap on OS paths, no?
15:41:01 <csaba> bswartz: or add the rule for both paths?
15:41:21 <nileshb> I think, this is a generic problem and might have been solved in other OpenStack projects
15:41:22 <bswartz> yeah I expect that distros would tailor the rootwrap for their own distro anyways
15:41:36 <bswartz> for upstream we can simply include both rootwrap paths
15:41:42 <tbarron> bswartz: +1
15:41:53 <bswartz> this seems like a really simple problem that doesn't require a complex solution
15:42:00 <csaba> nileshb: that's the question, is there prior art?
15:42:29 <csaba> bswartz: how is it done in devstack eg?
15:42:48 <nileshb> csaba: we will need to investigate
15:42:49 <csaba> devstack has to be able to manage services both on ubuntu and fedora
15:42:51 <toabctl> bswartz: +1
15:42:54 <bswartz> tbh I'm not sure
15:43:16 <bswartz> I think devstack does have special cases depending on the OS
15:43:18 <csaba> nileshb: +!
15:43:20 <toabctl> csaba: devstack has a start/stop wrapper
15:43:21 <csaba> +1
15:43:44 <csaba> toabctl: would it be reasonable to adopt that?
15:43:48 <nileshb> bswartz: what you suggested, i.e. to add paths suitable to various supported OS platforms, looks like a workaround, but it will work
15:44:06 <bswartz> yeah I'm in favor of just adding multiple paths to the rootwrap
15:44:30 <bswartz> having both /sbin/service and /usr/sbin/service in the rootwrap is not going to cause a security problem
15:44:35 <toabctl> csaba: I would, as bswartz suggests, just add both path for now.
15:44:38 <tbarron> KISS
15:44:55 <csaba> bswartz: and do you think we can count on service(8) availability everywhere?
15:45:25 <bswartz> csaba: I'm not sure of that, any SUSE folks here?
15:45:33 <nileshb> I believe, yes .. else we fail anyway
15:45:41 <toabctl> csaba: suse has it. seems to be a wrapper arround systemctl
15:45:54 <bswartz> okay
15:46:05 <csaba> toabctl: OK so for now service  with multple paths will be fine
15:46:15 <bswartz> alright!
15:46:23 <bswartz> anything else on this topic csaba?
15:46:33 <tbarron> that was Keep It Simple Stupid (since somebody asked me)
15:46:39 <csaba> no, I'm fine with this conclusion
15:46:46 <bswartz> #topic open disucssion
15:46:55 <bswartz> any last things?
15:47:03 <tbarron> not affection for anyone here :-)
15:47:07 <toabctl> maybe you discussed that already - is next week a meeting?
15:47:21 <nileshb> one thing
15:47:24 <cknight> tbarron: :-*
15:47:43 <bswartz> toabctl: next meeting will be 8 Jan 2015
15:47:51 <toabctl> bswartz: ok. thx
15:47:52 <bswartz> I'll update the wiki
15:48:02 <nileshb> I am just curious to understand what it takes to graduate manila from incubation status to integrated project status?
15:48:22 <vponomaryov> nileshb: size of community and core group
15:48:59 <bswartz> nileshb: http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst
15:49:08 <nileshb> do we expect to get to that state, in K release or L release?
15:49:46 <nileshb> Ok, I will look into the process offline
15:49:59 <nileshb> thnx
15:50:13 <bswartz> nileshb: we're trying to do it ASAP
15:50:47 <bswartz> the TC is going through some changes though, so I expect the goal line to get moved before we get there
15:51:08 <bswartz> I attend all the TC meetings and I'm trying to figure out what we should be doing
15:51:31 <bswartz> priority #1 though is to make manila good and useful -- if we don't do that then nothing else will matter
15:51:36 <nileshb> bswartz: sure, thanks
15:52:09 <bswartz> I'd like to thank all of the reviewers for their hard work on K-1
15:52:14 <nileshb> bswartz: lets all work towards it
15:52:29 <bswartz> anyone whose patches didn't make it for K-1, we'll try to get them in early in K-2
15:52:45 <bswartz> maybe even as early as this afternoon in the case of csaba
15:52:47 <bswartz> :-)
15:53:00 <csaba> \o/
15:53:10 <bswartz> that's all I've got
15:53:13 <bswartz> thanks everyone
15:53:16 <vponomaryov> https://review.openstack.org/#/c/124635/ can go right now =)
15:53:30 <nileshb> Merry Xmas to all, enjoy the holidays
15:53:31 <bswartz> vponomaryov: I'll review it right now
15:53:42 <bswartz> #endmeeting