15:00:57 <bswartz> #startmeeting manila
15:00:58 <openstack> Meeting started Thu Aug 21 15:00:57 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:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:02 <openstack> The meeting name has been set to 'manila'
15:01:04 <cknight> Hi
15:01:08 <tbarron> hi
15:01:10 <ameade> o/
15:01:11 <xyang1> hi
15:01:12 <bswartz> good morning/good afternoon/good evening
15:01:12 <deepakcs> hi
15:01:13 <vponomaryov> hi
15:01:22 <rraja> hi
15:01:36 <bswartz> we do have an agend
15:01:44 <bswartz> but I'll start with the incubation stuff
15:01:48 <bswartz> since I'm getting a bunch of questions about that
15:01:55 <scottda> hi
15:01:56 <bswartz> #topic incubation
15:01:58 <rushil> hi
15:02:04 <toabctl> hi
15:02:13 <vvechkanov> hi
15:02:23 <dustins> o/
15:02:42 <bswartz> so the TC is mostly positive on it
15:02:48 <bswartz> but the vote hasn't completed yet
15:02:55 <bswartz> for your reading pleasure:
15:02:59 <bswartz> #link http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-08-19-20.02.log.html
15:03:27 <bswartz> There is a thread on the ML which explains some of the TC member's hesitance:
15:03:28 <bswartz> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
15:03:54 <bswartz> the actual votes are here:
15:03:58 <bswartz> #link https://review.openstack.org/#/c/111149/
15:04:02 <bswartz> #link https://review.openstack.org/#/c/113583/
15:04:15 <bswartz> any questions about all that?
15:04:42 <xyang1> bswartz: how many +1 do we need?
15:04:46 <bswartz> 7
15:04:55 <bswartz> according to ttx
15:04:59 <deepakcs> bswartz, <ttx> 3. The driver/vendor aspect (avoid another Neutron with no first-party driver really viable, getting swamped by driver requests, relationship with glusterfs)
15:05:01 <xyang1> bswartz: so just missing 1
15:05:05 <deepakcs> bswartz, ^^ didn't understand that..
15:05:13 <xyang1> bswartz: is the -1 blocking?
15:05:27 <bswartz> deepakcs: so many people consider neutron a disaster of a project
15:05:27 <vponomaryov> xyang1: I guess no
15:05:49 <bswartz> because it's all vendor driven and there is a lack of a software-only implementation supported by the neutron core team
15:05:52 <ttx> bswartz: You actually need at least 4 YES and more YES than NO, but 7 gives you majority and immediate approval
15:05:54 <vponomaryov> xyang1: need 7 yes
15:06:14 <bswartz> manila doesn't have that problem, because we have a very highly functional generic driver that we support
15:06:16 <deepakcs> bswartz, relnship with glusterfs.. what is that ? :)
15:06:27 <ttx> err.. 5 YES
15:06:27 <bswartz> ttx: thanks for clarification
15:06:43 <ttx> (ref: http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n79)
15:07:13 <bswartz> deepakcs:  actually I didn't understand the comment about glusterfs
15:07:14 <toabctl> bswartz: so what's the solution for manila to avoid the Neutron scenario? good support for the current generic driver?
15:07:22 <bswartz> since we have ttx here, can he explain what he meant?
15:07:54 <ttx> bswartz: on tha (3) point,
15:08:02 <bswartz> toabctl: yes that's exactly the plan
15:08:31 <bswartz> we have plans to improve the generic driver in terms of scalability and HA
15:08:39 <ttx> That's a catch-all for the potential that Manila becomes another Neutron or Cinder
15:08:56 <bswartz> and also work on any issues with its performance in general (as much as can be done with a software-only driver)
15:09:00 <ameade> :q
15:09:12 <ameade> >.<
15:09:16 <ttx> bswartz: i.e. you receiveing hate mail from vendors you displease
15:09:27 <bswartz> ttx: I feel that cinder and neutron have gone very different directions culturally
15:09:32 <xyang1> ttx: what the problem with Cinder?  curious
15:09:42 <ttx> there were 3 concerns I lumped into that catch-all
15:09:43 <bswartz> my hope is to follow the path of cinder
15:09:51 <bswartz> no neutron
15:10:00 <bswartz> s/no/not/
15:10:09 <ttx> A. make sure you have an open source solution that works extremely well
15:10:16 <ttx> rather than a second-class citizen
15:10:38 <ttx> B. Try to keep the driver requests under control
15:10:46 <nileshb> opensource meaning - non-vendor-specific?
15:10:49 <ttx> so that you don't get swamped under them
15:10:55 <bswartz> ttx: do you characterize glusterfs as a second open source solution, or a vendor specific driver?
15:11:00 <ttx> nileshb: meaning open sourced.
15:11:12 <ttx> bswartz: glusterfs is open source.
15:11:21 <bswartz> okay I think we're on the same page then
15:11:47 <ttx> C. clarify the relationship with glusterfs, which I think we just discussed :)
15:12:08 <bswartz> ok
15:12:17 <ttx> just trying to learn from experience :)
15:12:21 <bswartz> any more questions on incubation or should I move on to the agenda?
15:12:54 <xyang1> ttx: when will we get verdict
15:13:11 <toabctl> so is glusterfs the main driver or the current generic driver?
15:13:30 <bswartz> fwiw, I'm aware of several vendor-specific drivers being worked on, and I'm excited to see them land because I think the existing of multiple drivers will prove our architecture is correct
15:13:48 <bswartz> toabctl: generic is the one the core team maintains and recommends
15:13:53 <ttx> xyang1: voting is asynchronous now. If we don't get a majority at next meeting, i'll call for final vote, which triggers the "5+YES and 4-NO" rule I mentioned above
15:14:09 <bswartz> so far the glusterfs work has been done exclusively by redhat, and we want to see it succeed
15:14:09 <toabctl> bswartz: ok. thx
15:14:15 <ttx> so worst case scenario, middle of next week
15:14:15 <xyang1> ttx: thanks
15:15:32 <bswartz> alright let's move on
15:15:56 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:16:06 <bswartz> #topic dev status
15:16:15 <vponomaryov> dev status:
15:16:18 <vponomaryov> 1) LVM driver was removed. Generic driver is default now.
15:16:27 <vponomaryov> 2) 'sid' share access rules were renamed to 'user'
15:16:39 <vponomaryov> 3) Removing dependency of NetApp 7-mode driver for NetApp Cmode driver
15:16:39 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/remove-netapp-7mode-driver
15:16:39 <vponomaryov> gerrit: #link https://review.openstack.org/113596
15:16:39 <vponomaryov> status: ready for review
15:16:47 <vponomaryov> 4) replacement of sqlalchemy-migrate with alembic
15:16:47 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/alembic-instead-of-sqlalchemy-migrate
15:16:47 <vponomaryov> gerrit: #link https://review.openstack.org/110959
15:16:47 <vponomaryov> status: ready for review
15:17:01 <vponomaryov> 5) Add support to use default network by multitenant drivers
15:17:01 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/default-network-for-multitenant-drivers
15:17:01 <vponomaryov> status: work in progress
15:17:12 <vponomaryov> that's the main
15:17:19 <bswartz> ty vponomaryov
15:17:34 <bswartz> we may want to discuss the last one
15:17:43 <bswartz> we disucussed it at length earlier this week
15:17:48 <bswartz> privately
15:18:11 <bswartz> oh wait that's the next agenda item
15:18:13 <bswartz> doh!
15:18:24 <bswartz> any questions on the rest of this stuff
15:18:58 <toabctl> why is the 7-mode driver removed ?
15:19:27 <bswartz> toabctl: that was the original driver we used as a POC for the manila concept like 2 years ago
15:19:44 <rushil> toabctl: according to my understanding it was poorly written.
15:19:51 <bswartz> it never had multitenant support, and NetApp didn't want to invest in adding multitenant support because netapp had mutlitenant support in the c-mode driver
15:20:12 <bswartz> rushil: not poorly written, just lacking features
15:20:51 <bswartz> anyways it served its purpose and we didn't need it anymore
15:20:57 <bswartz> similar to the 'LVM' driver
15:21:03 <rushil> bswartz: It can be brought back though, right?
15:21:17 <bswartz> it's in the git history if someone wants to resurrect it and implement all the missing stuff
15:21:34 <toabctl> bswartz: but then ONTAP running in 7-mode is no longer supported, right?
15:21:49 <bswartz> toabctl: correct
15:22:00 <toabctl> bswartz: ok. thx for clarification.
15:22:21 <bswartz> so far netapp hasn't expressed an interest in supporting 7mode under manila -- that may change
15:22:41 <bswartz> okay let's move on
15:22:59 <bswartz> #topic Discuss blueprint "Add support to use default network by multitenant driver"
15:23:12 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/default-network-for-multitenant-drivers
15:23:25 <vvechkanov> Ok, let's discuss blueprint "creating default share network for generic driver".
15:23:27 <bswartz> vvechkanov: you want to start this one?
15:23:53 <vvechkanov> bswarts, yes I can/
15:24:17 <vvechkanov> Now blueprint looks this way:
15:24:48 <vvechkanov> we will create default share_network in the service tenant.
15:25:10 <vvechkanov> This share network can be created by admin or will be created by manila automatically. This share network will be used for creating shares in any tenant if shared network is not specified in the request.
15:25:10 <vvechkanov> 
15:25:22 <vvechkanov> ut this plan have some problems. User, working in tenant will have shares, which will be created using this default shared network. But user has not acces to service tenant and can't see this shared network. So user will have share, but will not have possibility to look at some options which  network it works.
15:26:16 <vvechkanov> May somebody have ideas what can be done to avoid this problem? And is it a big problem that user will not see some configuration options of his hsare?
15:26:32 <deepakcs> vvechkanov, just confirming.. this idea of using share_network (if not provided) is only applicable to generic driver, rite ?
15:26:43 <bswartz> vvechkanov: so my feeling on this is that the "default" network shouldn't have any settings that users need to be aware of
15:27:09 <bswartz> it's the admins responsibility to configure it such that it works for all tenants
15:27:10 <nileshb> will the default network once created (automatically or by admin) be immutable?
15:27:22 <bswartz> nileshb: that
15:27:28 <vvechkanov> deepakcs, No i'm very sorry it's my mistake. It will be for all drivers.
15:27:28 <vvechkanov> I jsut forgot to rename blueprint(
15:27:30 <bswartz> nileshb: that's debatable
15:27:56 <scottda> I agree with bswartz. Users shouldn't need access to the network.
15:28:03 <bswartz> the default network will apply to all drivers
15:28:06 <scottda> for configuration, etc
15:28:19 <nileshb> so if the admin deletes it and someone creates a share without specifying net-id .. default n/w is already gone
15:28:29 <bswartz> and the non-multitenant-supporting drivers will use it exclusively
15:28:45 <deepakcs> vvechkanov, then i am bit confused, for cases where the backend supports multi-tenancy, why would share-network be needed to be enforced ?
15:28:50 <vvechkanov> nileshb, default network will be created again in this case.
15:29:30 <nileshb> ok .. then the original one .. no more exists .. which might have been used to create some of the previous shares
15:29:37 <vvechkanov> deepakcs, this idea works good whan we have flat netwrok in neutron
15:29:38 <bswartz> so deepakcs: consider the case of someone using the Netapp driver in a flat network environment
15:30:06 <bswartz> the netapp driver still needs to create a "share server" (vserver) and we need network info to do that
15:30:13 <bswartz> the same is true of the generic driver
15:30:19 <nileshb> probably admin should not be allowed to delete a default n/w .. if it is 'in-use'
15:30:26 <bswartz> we need to create a nova VM and it needs to live on a network
15:30:40 <rushil> vvechkanov: But what if scenario is when we do not have a flat network?
15:30:52 <vvechkanov> nileshb, if I understand you correctly... Administrator can't delete share networks if there are shares using it.
15:31:04 <vponomaryov> nileshb: it would be strange, if admin deletes usable things. In this case he should port shares to another server/network
15:31:09 <nileshb> vvechkanov: exactly
15:31:34 <bswartz> if we don't have a flat network, then the default share network may be inaccessible to tenants -- in which case they shoudn't use it
15:31:37 <vvechkanov> rushil, than nothing changes. User can't create shares without specifing share netwrok
15:31:47 <bswartz> in fact we may want to consider allowing the admin to explicitly disable it
15:32:30 <bswartz> I'm feeling pretty strongly that the default SHOULD be immutable as long as its in use
15:32:51 <nileshb> bswartz: +1
15:32:53 <bswartz> attempts to modify it should fail unless all shares using it are deleted
15:32:59 <bswartz> that includes deleting it
15:33:10 <bswartz> deleting the default share network, that is
15:33:26 <nileshb> deleting share looks tough
15:33:44 <bswartz> what do you mean?
15:33:44 <nileshb> do we allow detach n/w?
15:33:48 <vponomaryov> nileshb:
15:33:50 <bswartz> deleting a share is a basic operation
15:33:57 <nileshb> and reattach those to new n/w
15:34:26 <vponomaryov> nileshb: no, there are no functionality yet, if you mean migration of shres
15:34:38 <vponomaryov> s/shres/shares/
15:34:55 <nileshb> ok
15:35:09 <bswartz> the design of manila right now requires that shares have a share network and that association can never change
15:35:27 <nileshb> ok got it
15:35:37 <bswartz> it wouldn't be impossibe to change that but it would be really hard
15:35:56 <bswartz> the theory is that most tenants will have exactly one share network that they use and this won't be a big deal
15:36:07 <bswartz> tenant with special needs may create more than 1
15:37:20 <bswartz> no 2 tenants can share a share network (sorry for overloaded term)
15:37:28 <bswartz> except for the default one
15:37:50 <deepakcs> bswartz, a dumb Q (maybe)...
15:37:55 <xyang1> bswartz: why this restriction?
15:38:23 <deepakcs> bswartz, Do we still need a share-network if the backend manages its own multi-tenancy and User wants the instance to directly connect to backend
15:38:33 <deepakcs> bswartz, for eg: In case of glusterfs native protocol
15:38:39 <bswartz> xyang1: it simplifies implementation -- and we never identified any use case where tenants would need to share a share network
15:38:46 <vponomaryov> share-network belongs to tenant, but it depends on network itself, does two tenants has crossing access or not
15:39:06 <vponomaryov> deepakcs: do not forget about security services
15:39:13 <bswartz> if there is a legitimate reason to have a single share accessed by 2 or more tenants, than can be achieved with virtual routes between those 2 tenant's networks
15:40:09 <bswartz> but the share is still owned by 1 tenant and uses his security settings and his network settings
15:40:40 <xyang1> bswartz: I don't have a specific use case, just thinking about the possibilities
15:41:06 <bswartz> xyang1: we thought about is an discussed it at length several months ago because people asked the same question
15:41:06 <deepakcs> vponomaryov, not cler to me.. why do  I need a share-network in case of native glusterfs protocol
15:41:36 <vponomaryov> deepakcs: in case of glusterFS - no
15:41:48 <vponomaryov> deepakcs: the concept is required - yes
15:41:49 <bswartz> I'm comfortable with the decision we arrived at, but we can always revisit stuff if someone has a new use case we didn't consider
15:41:54 <deepakcs> vponomaryov, ok, but the above discussion said share-network will be created if not supplied
15:41:59 <vponomaryov> deepakcs: because it is used for other stuff by other drivers
15:42:15 <deepakcs> vponomaryov, so not clear if that affects my instance -> glusterfs server path/networking in any way
15:42:15 <vponomaryov> deepakcs: driver decides use it or not
15:42:23 <vponomaryov> no
15:42:31 <deepakcs> vponomaryov, ok, thanks
15:42:31 <vponomaryov> because driver makes decision
15:42:36 <deepakcs> vponomaryov, ok
15:42:42 <vponomaryov> =)
15:42:59 <bswartz> deepakcs: we need to discuss networking and glusterfs more because I have some ideas that may not match reality
15:43:21 <deepakcs> bswartz, sure, fire a mail or we can talk on IRC
15:43:27 <deepakcs> bswartz, due to TZ diff, mail is better
15:43:27 <bswartz> or maybe we just have some misunderstanding
15:44:07 <bswartz> my top priority is to make sure that the generic driver works well in both multitenant and single tenant environments, and that the setup for both is straighforward and easy to understand
15:44:12 <bswartz> errr
15:44:19 <bswartz> I meant flat network not single tenant
15:44:59 <bswartz> I think of flat networks as conceptually single tenant, even though many people use multitenant with flat network
15:44:59 <vponomaryov> bswartz: actually it works
15:45:19 <vponomaryov> bswartz: but only from neutron
15:45:32 <bswartz> vponomaryov: I know it works -- I just want to make sure it's really easy and straightforward
15:46:07 <bswartz> the fact that some developers aren't clear on this means we haven't done a good job of communicating how each type of environment should be setup
15:46:31 <bswartz> we probably need a wiki that goes into both types of configs
15:46:39 <rushil> bswartz: +1
15:46:54 <bswartz> that's another topic though
15:47:47 <bswartz> okay this is vvechkanov's topic though and we've gotten way off track
15:48:16 <bswartz> vvechkanov: are you clear on what the next step should be?
15:48:26 <bswartz> or do we need to summarize?
15:48:39 <vvechkanov> Yes, as I understand this idea looks good.
15:48:46 <bswartz> okay
15:49:07 <vvechkanov> So I'll provid commit on gerrit and we will look at it, and may be discuus in comments
15:49:15 <bswartz> okay
15:49:29 <bswartz> I always feel better debating code rather than abstract ideas in blueprints
15:50:18 <bswartz> vponomaryov: let's plan on setting aside some time soon to improve our wiki docs for how to setup both flat and vlan-based networks (perhaps other types too)
15:50:41 <bswartz> and making sure those docs cover the default network stuff when its done
15:51:19 <bswartz> #topic open discussion
15:51:34 <bswartz> okay 9 minutes left -- anyone have another topic to discuss?
15:51:55 <nileshb> Last week I have submitted GPFS driver code for review
15:52:11 <nileshb> which includes NFS Ganesha support with the ganesha utils
15:52:18 <nileshb> https://review.openstack.org/#/c/114311/
15:52:25 <bswartz> I'm going to be on vacation at the beach next week -- it's not clear if I'm going to miss this meeting or not, but if I have to miss I'll find someone to run it in my absence
15:52:37 <deepakcs> bswartz, and I submiited cert-based access type WIP for review (https://review.openstack.org/#/c/114736/). Looking fwd for comments.
15:52:42 <nileshb> Driver functionality is complete .. it is in WIP state since I am yet to submit unit tests for it
15:52:43 <bswartz> I'm hoping I'll be available
15:53:03 <bswartz> nileshb: awesome!
15:53:16 <bswartz> nileshb: I saw it but haven't reviewed it yet
15:53:20 <xyang1> We submitted VNX driver too: https://review.openstack.org/#/c/115188/
15:53:48 <bswartz> xyang1: I saw a few submissions
15:54:01 <nileshb> we believe the ganesha utils can be enhanced further and can become part of core manila project .. currently those reside under ibm/ dir
15:54:06 <bswartz> jenkins seems unhappy with both
15:54:30 <xyang1> xyang1: This is the base driver: https://review.openstack.org/#/c/115037/, VNX driver is the plugin to the base
15:54:38 <nileshb> there seems to be some jenkins issue .. not specific to driver code
15:54:38 <bswartz> are the failures easy to fix?
15:54:46 <xyang1> bswartz: I couldn't repro the jenkins errors on my setup
15:54:59 <bswartz> okay we may need to investigate
15:55:14 <vponomaryov> bswartz: ше шы шыыгу Ш ьутешщтув нуыеуквфн
15:55:27 <vponomaryov> bswartz: it is issue I mentioned yesterday
15:55:28 <bswartz> vponomaryov: english?
15:55:30 <xyang1> vponomaryov: ?
15:55:32 <vponomaryov> sorry =)
15:56:01 <bswartz> vponomaryov: I wasn't following the discussion closely enough yesterday
15:56:02 <bswartz> what issue?
15:56:05 <xyang1> vponomaryov: you have an idea why we hit those errors?
15:56:23 <vponomaryov> xyang1: dead dependency, it is fixed already
15:56:33 <bswartz> oh that one
15:56:35 <bswartz> is the fix merged?
15:56:39 <vponomaryov> xyang1:just need rerun jobs
15:56:49 <bswartz> recheck no bug?
15:56:56 <vponomaryov> "recheck"
15:56:56 <xyang1> vponomaryov: do we need rebase?
15:57:03 <xyang1> ok, will try that
15:57:08 <bswartz> k excellent
15:57:14 <nileshb> ok thanks
15:57:42 <bswartz> so 1 last thing
15:57:50 <bswartz> J-3 is coming soon
15:58:04 <bswartz> I'd like to get these drivers reviewed and merged if possible
15:58:38 <bswartz> so Juno can claim multivendor support in addition to the open source drivers
15:59:04 <bswartz> let's prioritize reviews until the J-3 cut date
15:59:07 <deepakcs> bswartz, and support for new access type too (hpefully) ;-)
15:59:34 <vponomaryov> bswartz: do you remember date itself?
15:59:45 <nileshb> 4th Sept?
15:59:47 <xyang1> bswartz: 9/4?
15:59:53 <bswartz> deepakcs: it needs to be complete and mergable soon
15:59:59 <bswartz> so we can do the reviews and get it done
16:00:14 <deepakcs> bswartz, given that most of the trust setup is out of band, there isnt much to do in manila..
16:00:28 <mihgen> hi folks
16:00:28 <deepakcs> bswartz, I would love to hear from you and others so that i can follow up and help get it merged soon
16:00:41 <bswartz> if it's not merged by 9/3 then it will need an exception
16:00:53 <bswartz> because 9/4 will be the branch date
16:01:01 <deepakcs> bswartz, yeah.
16:01:15 <bswartz> okay we're past time
16:01:24 <bswartz> thank all
16:01:25 <mihgen> any fuelers around?
16:01:27 <deepakcs> bye
16:01:27 <bswartz> thanks*
16:01:28 <xyang1> thanks
16:01:29 <cknight> bye
16:01:30 <bswartz> #endmeeting