15:00:46 <bswartz> #startmeeting manila
15:00:49 <openstack> Meeting started Thu Dec  4 15:00:46 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:53 <openstack> The meeting name has been set to 'manila'
15:01:05 <bswartz> hello all
15:01:06 <vponomaryov> hello
15:01:12 <rushil> \o
15:01:17 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:02:02 <bswartz> wow small group today
15:02:25 <bswartz> maybe the meeting will be quick
15:02:39 <csaba> hi
15:02:40 <bswartz> although csaba has some agenda items so I hope he showsu p
15:02:48 <bswartz> csaba: hi!
15:02:55 <bswartz> #topic dev status
15:03:06 <vponomaryov> Dev status:
15:03:12 <vponomaryov> 1) Driver modes:
15:03:18 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/driver-modes
15:03:22 <vponomaryov> gerrit: #link https://review.openstack.org/136714
15:03:25 <vponomaryov> status: ready for review
15:03:31 <vponomaryov> 2) Network helpers
15:03:35 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/network-helper
15:03:38 <vponomaryov> interface: #link https://review.openstack.org/137760
15:03:42 <vponomaryov> neutron implementation: #link https://review.openstack.org/136724
15:03:45 <vponomaryov> status: ready for review
15:03:50 <vponomaryov> 3) Functional tests in manilaclient
15:03:54 <vponomaryov> BP: #link https://blueprints.launchpad.net/python-manilaclient/+spec/functional-tests
15:03:55 <lpabon> hi
15:04:04 <vponomaryov> gerrit:
15:04:04 <vponomaryov> #link https://review.openstack.org/137393
15:04:04 <vponomaryov> #link https://review.openstack.org/138038
15:04:04 <vponomaryov> status: work in progress
15:04:12 <vponomaryov> that the main
15:04:24 <bswartz> okay cool
15:04:32 <vponomaryov> also we have additional driver in repo - GPFS
15:04:53 <bswartz> yes I know about gpfs
15:05:06 <bswartz> thanks for all the work that's gone into writing/reviewing that driver
15:06:23 <bswartz> oh and it looks like it got merged yesterday
15:06:31 <bswartz> that's great news
15:06:50 <vponomaryov> that's the point =)
15:06:54 <bswartz> congrats nilesh
15:06:59 <csaba> +1
15:07:21 <vponomaryov> also Nilesh provided good review on Huawei driver using expirience with his driver
15:07:40 <bswartz> vponomaryov: thanks for status update, I see some of those patches are in better shape now
15:08:01 <deepakcs> Hi all, joining late
15:08:04 <bswartz> I will be out of office until Tuesday so my reviews will be less until then
15:08:19 <bswartz> okay
15:08:22 <csaba> hi deepakcs :)
15:08:25 <bswartz> #topic kilo-1 milestone
15:08:46 <bswartz> so we are 2 weeks away from kilo-1
15:09:06 <bswartz> anything not currently in review probably won't get merged for kilo-1, unless it's small and easy
15:09:30 <bswartz> that's no big deal though, because kilo-1 is not a deadline for anything, it's just our first milestone
15:09:47 <bswartz> I wanted to call attention to this though:
15:09:50 <bswartz> #link https://launchpad.net/manila/+milestone/kilo-1
15:10:06 <bswartz> we have LOTS of bugs and blueprints
15:10:23 <bswartz> we need to figure out what's in and what's out for kilo-1 and start retargetting
15:10:49 <bswartz> also, if there's anything someone wants to get into kilo-1 that's not on that page, it's urgent that we fix that
15:11:00 <rushil> bswartz: Are we still working towards Non-VLAN Multitenancy on this list?
15:11:09 <bswartz> rushil: no
15:11:22 <bswartz> unfortunately there's some old stuff left over because I haven't cleaned up this list
15:11:28 <bswartz> that was sort of the point of this agenda item
15:11:39 <bswartz> we've been adding stuff and not cleaning up, which is my fault
15:12:20 <bswartz> expect to see stuff get pushed out and retargetted
15:12:34 <bswartz> if you disagree with any changes please raise the issue with me
15:13:03 <bswartz> any questions or things to add right now?
15:13:33 <lpabon> all good
15:13:36 <bswartz> cool
15:13:52 <bswartz> #topic resolving a name clash
15:13:59 <bswartz> csaba: you're up
15:14:04 <csaba> bswartz: thx
15:14:13 <bswartz> I'm a bit unclear on what this topic is...
15:14:26 <csaba> so, again congrats to Nilesh for getting GPFS in !
15:14:41 <vponomaryov> ah, now I see the clash
15:14:52 <csaba> however, with this I found a name clash with config var naming
15:14:53 <nileshb> Good to see GPFS manila driver making it to the list :)
15:15:31 <deepakcs> congrats nileshb
15:15:38 <rushil> congrats nileshb
15:15:49 <csaba> we are working the Ganesha framework and we use the config var 'ganesha_config_path' -- just as GPFS does, given that code also includes Ganesha tooling
15:16:18 <bswartz> ok
15:16:23 <csaba> so some renaming should occur in order to be able to get both code pieces in tree
15:16:37 <vponomaryov> csaba: reuse?
15:16:47 <bswartz> well, if it's a config option for the driver only, it's should be possible to reuse it
15:16:52 <bswartz> as long as the documentation for both options is the same
15:17:07 <csaba> vponomaryov: and what about multi-driver setup?
15:17:10 <bswartz> if we do that, then the config option should be moved out of both drivers into a common place
15:17:27 <vponomaryov> csaba: what problem do you mean using multi-driver setup?
15:17:30 <bswartz> csaba: each driver in a multi driver setup gets its own instances of config vars
15:17:38 <vponomaryov> csaba: config group provide enough isolation
15:18:07 <bswartz> the only thing that would prevent sharing of the config option is if it meant very different things for each driver and the documentation could not agree
15:18:08 <csaba> vponomaryov: that sounds good then
15:18:23 <csaba> then it's just a technical problem
15:18:24 <vponomaryov> csaba: just stop using DEFAULT group for everything and use separated groups
15:18:53 <csaba> OK so technically the problem is that both options live in DEFAULT?
15:19:11 <vponomaryov> csaba: this is the only possible way to get a clash
15:19:30 <csaba> semantically I can confirm there is no problem as it's used in the same sense in both places
15:19:43 <deepakcs> vponomaryov, nileshb i still feel that ganesh_config_path is more appropriate as gpfs_ganesha_path, until GPFS migrates to using common ganesha tooling
15:19:44 <bswartz> csaba: if you've never done a multi backend/multi driver setup I'm sure we can help you with how to do it
15:20:01 <lpabon> should there be a review of driver configurations that are in the DEFAULT section, and have them moved?
15:20:11 <bswartz> deepakcs's point is the point we should be discussing here
15:20:17 <vponomaryov> lpabon: it is up to deployer
15:20:23 <vponomaryov> lpabon: nothing to code itself
15:20:44 <lpabon> vponomaryov: cool
15:20:48 <nileshb_> The Ganesha support added with GPFS driver is for Ganesha v1.5,2.0
15:21:00 <bswartz> lpabon/csaba: you can look at examples for how cinder handles multi-backend if you want good documentation on this
15:21:03 <nileshb_> what csaba is developing is for ganesha v2.1+
15:21:16 <nileshb_> so both can co-exist
15:21:25 <vponomaryov> bswartz,csaba: our tempest job has example
15:21:35 <csaba> nileshb_: given we want a generic solution we plan to add support for 1.5/2.0 as  well
15:21:45 <deepakcs> nileshb_, but looking at the config var it should be clear to the dev which is driver specific and which is part of common, no ?
15:21:48 <vponomaryov> http://logs.openstack.org/42/138242/5/check/gate-manila-tempest-dsvm-neutron-multibackend/c00c641/logs/etc/manila/manila.conf.txt.gz
15:21:50 <bswartz> nileshb_: do you object to renaming ganesha_config_path to gpfs_ganesha_path as deepakcs suggests?
15:21:58 <csaba> vponomaryov, bswartz : thanks, I'll check out
15:22:02 <deepakcs> since the eventual plan is to have all drivers use the common tooling
15:22:29 <csaba> are there generic principles / guideline about variable scoping?
15:22:54 <csaba> or just "put to DEFAULT until conflict arises then move elsewhere?"
15:23:03 <bswartz> the general principle is that anything driver specific should be prefixed with the name of the driver (or an abbreviation)
15:23:10 <vponomaryov> csaba: I would reccomend to use config groups any time
15:23:20 <nileshb_> it is currently defined inside gpfs.py .. if we take it out GPFS can also re-use it
15:23:32 <bswartz> however for stuff that can be shared, we should try to pick names that work for everyone and then share them
15:23:40 <rushil> bswartz: +1
15:23:49 <vponomaryov> but I am agree, driver specific stuff should have prefix
15:24:06 <nileshb_> right .. thats why I do not want to add gpfs_ prefix to this common option
15:24:27 <deepakcs> nileshb_, having gpfs specific path will aid in debug i hope, otherwise if its 1 var.. both gpfs and common tool use it.. i think it will cause amibuigity ?
15:24:29 <csaba> nileshb_: but as long as we have two impementations we should be able to provide two different values simultaneously
15:25:05 <bswartz> deepakcs: ambiguity is okay as long as both drivers use the config option for the same purpose
15:25:07 <vponomaryov> csaba: only for case, when ONE driver uses both
15:25:28 <nileshb_> we can probably use prefixes .. ganesha20_ and ganesha21_
15:25:43 <deepakcs> bswartz, but in the .conf for GPFS backend we use generic config option.. it feels like GPFS is using common ganesha, but in reality it doesnt
15:25:45 <bswartz> documentation can clear up what limitations exist for GPFS or gluster -- I don't expect any problems in practice from 2 drivers using 1 option
15:25:49 <csaba> nileshb_: version support is a moving point
15:26:11 <csaba> it's implementational matter that should not be wired into config
15:26:23 <bswartz> this option should not be set at the global level anyways, since only the drivers care about it
15:26:46 <vponomaryov> csaba: can you create doc with description of concern?
15:26:47 <bswartz> gluster will have its instance of the config flag and gpfs will have another
15:26:49 <nileshb_> if we have a better implementation that works for GPFS as well, I am fine to drop mine
15:27:17 <deepakcs> bswartz, in a multi-backend scenario.. if one backend uses ganesha common tooling and another GPFS driver, both will have same config option for ganesha, no ?
15:27:21 <bswartz> the main thing is to move the definition for that option out of the gpfs driver because drivers should not be referring to eachother
15:27:36 <bswartz> deepakcs: yes, that's common and no big deal
15:27:55 <bswartz> each driver will have it's own instance and its own value
15:27:59 <vponomaryov> bswartz: one driver can not use opts from another driver
15:28:12 <bswartz> that's an easy thing to fix though
15:28:21 <vponomaryov> only move it out to common place
15:28:24 <deepakcs> bswartz, reusing config var is fine...but here the 2 options land up in entirely diff code bases which isn't obvious from the var.. that was my concern, but I am fine, it others don't see it
15:28:30 <csaba> nileshb_: btw afaics you _mostly_ adhere to prefixing your vars wtith gpfs_ -- why do you do otherwise in this case
15:28:30 <bswartz> who will take the action to fix the code and move the driver to a place where it can be shared?
15:28:56 <bswartz> s/driver/config option/
15:29:37 <csaba> bswartz: we can do it but an agreement would be good to have beforehand whether to apply gpfs_ prefix
15:29:50 <nileshb_> csaba while your implementation is under review, can we move GPFS ganesha implementation to a common place?
15:29:58 <bswartz> I think we're agreeing that it should NOT be prefix and therefore it should be moved
15:30:03 <bswartz> prefixed
15:30:19 <bswartz> I've not heard a good argument for having 2 different copies of this config option
15:31:04 <bswartz> there will be 1 option, both drivers can use it, and we just need to refactor the code to allow that
15:31:07 <csaba> bswartz: you meant, "it should NOT be prefixless"?
15:31:07 <nileshb_> right, we do not need the common config options to be prefixed by driver specific names
15:31:33 <nileshb_> each backend can have its own value associated with a config option
15:31:40 <bswartz> I mean it should not be renamed, the current name (with no prefix) is fine
15:32:08 <csaba> bswartz: OK
15:32:16 <bswartz> then gluster can import the same option and use it however it likes and nothing bad will happen
15:32:17 <vponomaryov> agree with bswartz: move existing opt from driver module to common place and reuse it
15:32:21 <nileshb_> even two backends using the same driver can have different values for the same config opt
15:32:25 <vponomaryov> without prefix
15:32:53 <bswartz> okay
15:32:53 <rushil> makes sense to move it into a common place, rather than adding the prefix
15:33:00 <csaba> bswartz: but the common place approach does not allow the two backends being used simultaneously
15:33:10 <bswartz> csaba: I disagree
15:33:21 <rushil> csaba: Why
15:33:22 <rushil> ?
15:33:35 <bswartz> csaba: I think this whole issue comes from your misunderstanding of how config options work
15:33:36 <xyang1_> csaba: each backend can set the option to a unique value
15:33:53 <csaba> does common place allow to having it used in different sections?
15:33:57 <bswartz> each driver will get its own instance of the shared config option
15:34:05 <bswartz> yes, absolutely
15:34:15 <csaba> bswartz: OK cool thanks for clarifying
15:34:29 <csaba> this sounds to be then a correct approach
15:34:46 <bswartz> if you need help with the implementation, I'm sure one of us can show you how to write the code and what to put in the config file
15:34:53 <nileshb_> so shall I move ganesh_utils from ibm/ to common location?
15:35:22 <vponomaryov> nileshb_: talk to csaba and deepak to cooperate
15:35:36 <nileshb_> vponomaryov: sure
15:35:46 <bswartz> nileshb_: just move the config flag from where it is to a common place
15:35:59 <bswartz> don't move the implementation unless you plan to also share that with glusterfs driver
15:36:25 <bswartz> one config option can have 2 different implementations depending on which driver is using it
15:36:27 <nileshb_> ok, we will take it offline and come up with a plan
15:36:31 <bswartz> thanks
15:36:35 <csaba> cool, thanks
15:36:36 <bswartz> #topic git-review-branch
15:36:50 <csaba> I just coded up a little utility
15:37:09 <csaba> and I'm sharing in the hope of other seeing it to be useful and getting feedback
15:37:31 <csaba> #link https://github.com/csabahenk/git-review-branch
15:37:50 <csaba> it's point is to help reviews
15:38:02 <csaba> basically it takes further what git review does
15:38:14 <csaba> with: git review --compare <change>,<patchset>[,<patchset>]
15:38:34 <bswartz> argh! why did you use ruby?
15:38:37 <vponomaryov> csaba: so, this is offline tool to view diffs?
15:38:56 <bswartz> lol
15:39:16 <csaba> bswartz: I'm most comfortable with ruby, I use it for prototyping -- if there is reason to integrate can be rewritten in pythion
15:39:21 <csaba> vponomaryov: kind iof
15:39:30 <bswartz> csaba: does this let me compute the diff between 2 patchets that are not related to rebasing against upstream?
15:39:42 <bswartz> that's one thing I dislike about gerrit
15:39:43 <lpabon> csaba: you should propose this to the git-review team (after changing it to python :-) )
15:39:45 <csaba> it builds a branch of all patchests that can be brought to a common base without conflict
15:40:05 <bswartz> when you do a rebase, reviewers can't tell if you made any changes not related to the rebase in that patchset
15:40:20 <csaba> bswartz: it's in the scope of a single change
15:40:25 <bswartz> lpabon: +1
15:40:38 <clarkb> bswartz: git review supports that
15:40:50 <bswartz> clarkb: it does?
15:40:52 <csaba> lpabon: sure it's just a release ealry practice that I publish it on this forum
15:40:53 <clarkb> yes...
15:40:54 <bswartz> oh please tell me how
15:41:35 <clarkb> I believe it is the -m option you provide it two patchsets
15:41:44 <clarkb> by I don't seem to have the man page installed here. one sec
15:41:52 <csaba> clarkb: -m is short for --compare
15:42:00 <bswartz> clarkb: is that something the web UI can do or is it a CLI only thing?
15:42:18 <clarkb> bswartz: the web ui for gerrit does not do that
15:42:29 <clarkb> git review -m changenumber,ps1-ps2
15:42:41 <csaba> clarkb: however that still brings in some junk
15:42:47 <clarkb> csaba: it should not
15:42:48 <bswartz> clarkb: thanks I will try that
15:42:54 <clarkb> csaba: it should rebase them to a common HEAD then diff
15:43:05 <deepakcs> clarkb, that gives u diff of 2 patchsets for the same change, right ?
15:43:11 <csaba> clarkb: see this for example: git review -m I6664054ba52d03814cea846cb0d79cd853632814,15-16
15:43:12 <deepakcs> clarkb, in which case, the GUI also does it!
15:43:37 <bswartz> so csaba: how is your project different than git review -m?
15:43:43 <clarkb> deepakcs: yes the difference is in cleaning out unrelated rebase data
15:43:44 <deepakcs> but i thought bswartz wanted somethign different
15:43:51 <clarkb> deepakcs: what the ui does not do is move both commits to a common head
15:44:03 <clarkb> what I read bswartz as wanting is move to common head then calculate the diff
15:44:20 <bswartz> I'm still not clear one what this new project does
15:44:24 <csaba> bswartz: gives you a dedicated branch for the change where you can overview the whole patchset serires of the change and you can update it
15:44:24 <bswartz> clarkb: yes
15:44:54 <deepakcs> clarkb, ah ok, i need to check the cli then
15:44:58 <csaba> so "git review -m I6664054ba52d03814cea846cb0d79cd853632814,15-16" gives you a diff in contrib/tempest/tempest/cli/manilaclient.py
15:45:15 <csaba> which is junk
15:45:45 <csaba> it's the gpfs change, and that did not muck with tempest for sure
15:46:05 <bswartz> okay
15:46:28 <bswartz> well it sounds like both the existing CLI tool and your project are improvements over what I've been doing
15:46:32 <clarkb> csaba: if --compare does not do what I describe in some cases I believe that would be a bug
15:46:33 <csaba> my tool gives you clear diffs AFAI tested, and allows you to keep it around and update for an elongated review process
15:46:37 <clarkb> csaba: and patches to git review are welcome
15:47:13 <bswartz> csaba: I hope you keep working on making your tool better with a goal of making it part of the official tool eventually (or to fix bugs in the official tool if they exist)
15:47:52 <bswartz> from what I'm hearing, there might just be a bug in how git review is handling your use case csaba
15:48:03 <csaba> bswartz: yes so I pitch it here to see if anyone else would find this enhancement useful before gettting too far with it
15:48:32 <bswartz> it definitely sounds useful -- I will have to try both options to see which is more useful
15:48:35 <csaba> bswartz: apart from bugs, the permanence I provide is a feature that can be seen as useful
15:49:16 <bswartz> csaba: are you open to using python instead of ruby? it sounds like that might be a sticking point if you ever want to integrate with the git-review project
15:49:31 <csaba> bswartz: of course
15:49:51 <bswartz> okay cool
15:50:08 <csaba> it's not a big deal to do a python rewrite
15:50:19 <bswartz> #topic open discussion
15:50:29 <bswartz> anyone have something else for today?
15:50:34 <deepakcs> csaba, and when u do the rewrite, pls consider adding nice comments :)
15:50:42 <deepakcs> csaba, so that its easy for others to follow and review :)
15:50:43 <nileshb_> yes
15:50:59 <nileshb_> I wanted to know if anyone has tried manila with docker
15:51:16 <nileshb_> this came up in one of our internal discussions
15:51:31 <bswartz> I have not
15:51:46 <bswartz> what context were you thinking about though nileshb_?
15:51:54 <vponomaryov> nileshb_: I ddid not, but containers do not allow to use kernel based Apps such as NFS server daemon
15:52:11 <bswartz> running manila inside a docker instance, or using docker for "service VMs" behind manila?
15:52:11 <nileshb_> vponomaryov: ok
15:52:19 <nileshb_> vponomaryov: bug Ganesha NFS is user based
15:52:34 <mkoderer> bswartz: btw are you ok if I update the manila wiki with the discussed use-cases?
15:53:10 <nileshb_> bswartz: using manila shared from docker containers
15:53:10 <vponomaryov> nileshb_: so, it can be said, that docker is not applied for all cases
15:53:10 <bswartz> We did spend a lot of time experimenting with linux container-based virtualization last year, and concluded that it was a nonstarter due to the lack of mature user-space NFS daemons
15:53:22 <vponomaryov> s/applied/applyable/
15:53:31 <xyang8> I tried to use nfs Ganesha with docker a while ago n
15:53:34 <bswartz> that was before we knew about ganesha however, so I'm open to exploring that topic again
15:53:41 <xyang8> But had problems
15:54:03 <nileshb_> xyang8: great
15:54:20 <nileshb_> I can also explore this thing
15:54:22 <csaba> xyang8: it would be interesting to give a detailed account on that , somewher
15:54:44 <xyang8> I didn't proceed though
15:54:51 <bswartz> nileshb_: I would still have concerns about other things that remain in the kernel though
15:55:09 <nileshb_> like?
15:55:27 <nileshb_> we just need the NFS export to be mounted inside the docker container right?
15:55:37 <bswartz> do linux containers allow each container to have a different timezone, DNS resolver, domain name, kerberos realm, etc?
15:55:43 <nileshb_> manila will run outside of the docker container
15:56:41 <nileshb_> I am not much familiar with lxc or docker .. need to explore these
15:57:21 <bswartz> As long as the container provides enough separation for everything that can affect the NFS client-server interaction, then it seems like a workable plan
15:57:48 <nileshb_> there were some questions regarding networking
15:57:53 <bswartz> just be on the lookout for stuff that's still shared due to the lack of full virtualization
15:58:26 <bswartz> and real quick, mkoderer: which wiki and what updates did you have in mind?
15:58:47 <vponomaryov> bswartz: mentioned in mail-list
15:59:03 <mkoderer> bswartz: https://wiki.openstack.org/wiki/Manila/usecases
15:59:09 <bswartz> oh yes
15:59:18 <mkoderer> bswartz: the one is outdated anyway :)
15:59:23 <bswartz> mkoderer: please update it
15:59:31 <bswartz> the wikis are always out of date, sadly
15:59:31 <mkoderer> ok
15:59:39 <bswartz> at least they're easy to update
15:59:53 <bswartz> we just have to remember to update them, then actually do it
16:00:01 <bswartz> okay we're out of time
16:00:02 <mkoderer> all right
16:00:04 <bswartz> thanks all
16:00:07 <vponomaryov> thanks
16:00:11 <xyang8> Thanks
16:00:18 <bswartz> #endmeeting