15:02:09 <bswartz> #startmeeting manila
15:02:09 <openstack> Meeting started Thu Apr 17 15:02:09 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:13 <openstack> The meeting name has been set to 'manila'
15:02:26 <bswartz> hello all
15:02:31 <vponomaryov> hi
15:02:36 <shamail> Hi everyone.
15:02:49 <rraja> hi
15:03:02 <xyang1> hi
15:03:26 <bswartz> hey in case some of you weren't aware, there are no more unconference sessions
15:03:52 <bswartz> at the design summit, there is now a dedicated track for "other projects"
15:04:00 <bswartz> #link http://summit.openstack.org/cfp/details/341
15:04:28 <bswartz> I'm not sure how the organizers pick and schedule submissions for the other projects track
15:04:31 <bswartz> does anyone know?
15:04:58 <xyang1> I think one project only gets one slot
15:05:33 <bswartz> yes one reason for the new system is to prevent unoffiicial projects from taking 2 or more slots
15:05:43 <xyang1> projects closely related to openstack will be given high priority
15:05:59 <xyang1> so I think Manila should be able to get one slot
15:06:01 <bswartz> I hope we get at least 1 slot and it hope the time doesn't conflict with anything
15:06:48 <bswartz> #topic dev status
15:06:49 <shamail> I wonder who/where we have to post with.
15:06:59 <bswartz> shamail: see my link above
15:07:05 <vponomaryov> Dev status:
15:07:10 <vponomaryov> 1) volume types for multibackend support
15:07:10 <vponomaryov> db changes: #link https://review.openstack.org/#/c/87975/
15:07:10 <vponomaryov> api changes: #link https://review.openstack.org/#/c/88282/
15:07:10 <vponomaryov> status: work in progress
15:07:22 <vponomaryov> 2) list of services
15:07:23 <vponomaryov> manila: #link https://review.openstack.org/#/c/88300/
15:07:23 <vponomaryov> client: #link https://review.openstack.org/#/c/88232/
15:07:23 <vponomaryov> status: work in progress
15:07:42 <vponomaryov> 3) Horizon, unittests has been implemented
15:07:42 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/horizon-integration
15:07:42 <vponomaryov> code: #link https://github.com/NetApp/horizon/tree/manila
15:07:42 <vponomaryov> status: beta-available
15:07:58 <vponomaryov> that's all
15:08:04 <bswartz> vponomaryov: thank you
15:08:16 <bswartz> so the horizon stuff is more or less ready to use
15:08:29 <bswartz> please file bugs if you find any
15:08:42 <bswartz> I guess we should file them against manila even though the bugs would be in the horizon code...
15:08:42 <vponomaryov> yes, but further should be added volume types support, etc
15:09:40 <bswartz> there was a lot of discussion earlier this week on how volume types should work with mutlibackend and relationships between share-networks and SVMs
15:10:03 <bswartz> I'll state my position in case anyone feels that we need to discuss it
15:10:49 <bswartz> Whether manila creates an SVM for any given new share is an implementation detail that should be hidden from the user
15:11:18 <bswartz> Manila should attempt to reuse existing SVMs where possible but it is valid to create a new SVM for every share if needed
15:11:47 <bswartz> and there will be cases where having multiple SVMs for a single share-network will be unavoidable, due to volume_types
15:12:29 <bswartz> for reference, SVM = "service VM" or "storage VM" (on netapp)
15:12:50 <bswartz> there is one complication here though
15:13:17 <bswartz> while we'd like to keep SVMs as an implementation detail hidden inside the backends, it's not possible to efficiently reuse them if the schedules doesn't know about them
15:13:55 <bswartz> we need to come up with a design that allows the schedulers to make the right decisions w.r.t. reusing SVMs while avoiding exposing too much of the details of the backend to the scheduler
15:14:05 <bswartz> I don't have a solution to that problem yet
15:15:01 <bswartz> deleting SVMs will be up the backends as well -- the default behaviour should be to delete them immediately when they're no longer needed, although one could imagine an optimizaiton that made deletion lazy
15:15:28 <bswartz> I'm not a fan of optimizing prematurely, so we'll implement that only if needed
15:16:07 <bswartz> any comments?
15:16:12 <shamail> Couldn't that detail be handled by the driver implementation?  E.g. It decides whether a new SVM is needed.
15:16:26 <vponomaryov> also one problem: request for deletion/update of share-network - we need to know are we allowed to do it at request time or not
15:16:32 <shamail> SVM = vFiler or am I misunderstanding the term?
15:16:33 <bswartz> shamail: yes, I want the driver to be free to create or reuse at its own discretion
15:16:57 <bswartz> shamail: a vfiler is one form of SVM -- we also call them vservers in our newer software
15:17:06 <shamail> True, thanks.
15:17:43 <bswartz> vponomaryov: I think we agreed that we will deny deletion requests if any shares exist
15:18:03 <bswartz> vponomaryov: we should also deny updates if they would be disruptive to existing shares
15:18:42 <shamail> Couldn't the BE provide available VIF information to the scheduler?  Then SVM could be created or reused based on VIF availability by the driver.
15:19:31 <bswartz> the backend will need to provide something to the scheduler, but I'm not sure what
15:19:46 <shamail> I hear you.
15:20:50 <bswartz> and this discussion is also closely tied to the gateway-based multitenancy solution as well
15:21:31 <bswartz> because if the scheduler chooses a glusterfs backend (for example) then manila will need to create a gateway SVM to provide multitenancy
15:23:16 <bswartz> there will be situations where there may be 2 drivers running at the same time
15:23:40 <bswartz> one multitenant aware and the other not (say netapp and glusterfs, for example)
15:23:56 <shamail> Do you think this is something that could be hinted via extra_spec type functionality?
15:24:08 <bswartz> the scheduler should not prefer one or the other based on multitenancy requirements -- preference should be up to the administrator
15:24:39 <bswartz> however once a share is created and an SVM exists, then future shares should reuse the SVM if possible
15:24:59 <bswartz> shamail: no because this isn't some static attribute
15:25:41 <vponomaryov> bswartz: do we keep in mind, that in future can be more that one SVM for one share-network and one backend?
15:25:42 <bswartz> at any given time a bunch of SVMs will exist for various share-networks and that mapping will be constantly changing
15:26:04 <shamail> Great point.
15:26:05 <bswartz> vponomaryov: yes absolutey
15:26:18 <shamail> I'll have to think over this offline a bit.  I'll let you know if anything comes to mind.
15:26:20 <bswartz> absolutely*
15:26:57 <vponomaryov> when should be created second SVm and not reused first one?
15:27:05 <bswartz> I suspect that manila itself may need to track SVMs in the database, but only in a way that's vendor-neutral
15:27:27 <bswartz> vponomaryov: if the existing SVM cannot support the requested volume_type, for example
15:27:43 <bswartz> vponomaryov: or if the existing SVM has no available capacity
15:28:02 <bswartz> in both cases it may be possible to create another SVM on teh same backend, or manila may need to go to another backend
15:29:15 <bswartz> I'm leaning towards having some generic concept of a SVM tracked within manila, with some admin-only mangement commands
15:29:36 <bswartz> that way the scheduler will have access to the information
15:30:48 <shamail> bswartz: +1 we need the information but it shouldn't have as much relevance for users.
15:30:52 <bswartz> rraja: is this compatible with your thinking on gateway-based multitenancy?
15:31:05 <bswartz> shamail: yes it should be completely hidden from the users
15:33:00 <bswartz> I may have to check back with rraja later
15:33:08 <bswartz> #topic open discussion
15:33:12 <bswartz> okay any other topics?
15:34:44 <bswartz> sounds like nothing else today
15:34:51 <bswartz> thanks everyone
15:34:55 <vponomaryov> thanks
15:35:04 <bswartz> #endmeeting