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