15:01:35 <bswartz> #startmeeting manila
15:01:36 <openstack> Meeting started Thu Oct 23 15:01:35 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:39 <openstack> The meeting name has been set to 'manila'
15:01:52 <bswartz> hello all
15:01:53 <scottda> hey
15:01:54 <tbarron> hi
15:01:55 <jasonsb> hi
15:01:56 <vponomaryov> hello
15:02:02 <dustins_> o/
15:02:03 <csaba> hi
15:02:14 <rushil1> hi
15:02:14 <xyang1> hi
15:02:21 <bswartz> I didn't have a formal agenda but vponomaryov has fixed that
15:02:21 <lpabon> hi
15:02:29 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:00 <bswartz> one thing quick before we start the agenda
15:03:05 <bswartz> #topic design summit
15:03:14 <bswartz> #link http://kilodesignsummit.sched.org/
15:03:33 <bswartz> the topics we agreed on last meeting have been posted, since I didn't get any new suggestions since last week
15:03:52 <bswartz> it's still possible to change these, but only if someone has a really compelling idea
15:04:03 <bswartz> if you want to suggest a change start a ML thread ASAP
15:04:25 <bswartz> that's all I have on the design summit
15:04:32 <bswartz> questions before we move on?
15:04:36 <csaba> bswartz: I sent a mall yesterday
15:04:57 <bswartz> csaba: oh yes
15:05:26 <bswartz> csaba: it wasn't clear to me that was a design summit session proposal
15:05:32 <bswartz> is that how you intended it?
15:05:42 <bswartz> or a topic for the manila team meetup?
15:06:03 <bswartz> personally I felt it made sense for the team meetup
15:06:58 <csaba> http://lists.openstack.org/pipermail/openstack-dev/2014-October/049001.html
15:07:32 <csaba> Yes my idea was for the summit originally
15:07:43 <bswartz> well let's discuss it here
15:07:54 <vponomaryov> csaba: I guess team meetup is enough for it
15:07:58 <bswartz> hopefully everyone has read the message or if not the link is there
15:08:21 <csaba> Ok thanks
15:08:23 <bswartz> the proposal seems pretty technical in nature\
15:08:52 <xyang1> design summit usually has a broader audience.  so code refactor fits better at the meetup
15:08:56 <bswartz> I think we can discuss it as a team during the meetup -- I don't imagine that there's much cross-project interest here
15:09:30 <rushil1> csaba: I believe that this can be discussed but doesn't need a design slot
15:09:53 <bswartz> okay I think there's agreement
15:09:59 <bswartz> we'll add this to the agenda for the meetup
15:10:15 <bswartz> by next week I'll collect all the topics that aren't being covered in the design summit and we'll form an agenda for the meetup
15:10:23 <bswartz> this one will definitely be included
15:10:36 <bswartz> tbh I don't know how much time we'll have on Friday for the meetup
15:10:40 <bswartz> does anyone know?
15:10:51 <vponomaryov> I don't
15:11:02 <xyang1> I don't either
15:11:04 <bswartz> it appears to be a whole day Friday
15:11:12 <bswartz> from 9AM-5:20PM
15:11:24 <csaba> rushil1: OK thanks for clarification, sounds good
15:11:25 <bswartz> so 8 hours minus breaks and lunch
15:11:47 <vponomaryov> bswartz: there will be only one meetup?
15:12:09 <bswartz> you know I'm pretty fuzzy on the details
15:12:21 <bswartz> I actually don't see manila listed here explicity as a meetup topic
15:12:27 <bswartz> but I've been told we'll have space
15:12:41 <xyang1> Cinder has 9-12:30 on Friday
15:12:49 <vponomaryov> so, I guess, it is some kind of flexible?
15:12:56 <xyang1> that is posted
15:13:01 <bswartz> yeah
15:13:30 <bswartz> regardless of how much time we'll have, we'll have too much to discuss
15:13:46 <bswartz> so I'll take a stab at prioritizing the list and we'll get as far though it as we can
15:13:54 <bswartz> expect that for next week
15:14:08 <bswartz> now back to our original agenda...
15:14:21 <bswartz> #topic dev status
15:14:29 <vponomaryov> dev status:
15:14:37 <vponomaryov> 1) Enhancement of share manager
15:14:40 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/enhance-share-manager
15:14:47 <vponomaryov> gerrit:
15:14:48 <vponomaryov> #link https://review.openstack.org/129843
15:14:48 <vponomaryov> #link https://review.openstack.org/129844
15:14:48 <vponomaryov> status: work in progress
15:14:56 <vponomaryov> 2) Manila share-networks-list API filtering:
15:15:02 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/improve-share-network-list-filtering
15:15:05 <vponomaryov> gerrit, server: #link https://review.openstack.org/130147
15:15:06 <vponomaryov> gerrit, cleint: #link https://review.openstack.org/129849
15:15:09 <vponomaryov> status: work in progress
15:15:19 <vponomaryov> 3) Manila snapshots list API
15:15:35 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/improve-snapshot-list-filtering
15:15:39 <vponomaryov> server: #link https://review.openstack.org/128740
15:15:39 <vponomaryov> client: #link https://review.openstack.org/127622
15:15:39 <vponomaryov> status: ready for review
15:15:54 <vponomaryov> that's the main
15:16:46 <bswartz> any question on the above?
15:17:32 <bswartz> cool
15:17:44 <bswartz> #topic Kilo Network Changes
15:17:50 <vponomaryov> #link https://wiki.openstack.org/wiki/Manila
15:18:03 <vponomaryov> #link https://wiki.openstack.org/wiki/Manila/Kilo_Network_Changes
15:18:07 <bswartz> so this is a work in progress
15:18:49 <vponomaryov> main idea - propose and make opinions on networking changes
15:18:54 <bswartz> As everyone (hopefully) knows, we've been thinking about how to make Manila usable in a wider variety of use cases
15:19:12 <bswartz> In particular, the feedback I've gotten from developers trying to write drivers is that it's very hard
15:19:38 <bswartz> we can/should make some changes to simplify configurations which have no reason to be complex
15:20:04 <vponomaryov> such as dependency on share-network
15:20:17 <vponomaryov> as share-server set up
15:20:22 <bswartz> I'm approaching this problem by first trying to enumerate all of the use cases that we want to serve so we can figure out which are/aren't served particularly well by the current design
15:20:46 <bswartz> then as we propose new designs, we can evaluate them against all of the use cases we want to address
15:21:11 <bswartz> hopefully it goes without saying that any change we make should be a non-disruptive as possible to existing users
15:21:40 <bswartz> but I'm willing to create a v2 API if we determine that backwards compatibility can't be maintained for some new feature that we really need
15:22:20 <bswartz> the main proposals I'm making now are:
15:22:27 <bswartz> 1) Cross-tenant share servers
15:22:35 <bswartz> 2) Cross-tenant share networks
15:23:14 <bswartz> later I'll also be proposing mechanisms to run without neutron because various use cases demand that
15:23:48 <bswartz> so this document is sort of a sneak peak at what I'll be proposing in Paris
15:24:14 <bswartz> I intentionally made it a wiki so anyone can contribute and so that the design is out in the public
15:24:31 <bswartz> it's not really "done" though so don't judge it as such
15:25:01 <rushil1> bswartz: We do plan to use the existing neutron setup for VLAN, VXLAN and GRE scenarios. Right?
15:25:31 <bswartz> rushil1: neutron support isn't going away
15:25:52 <bswartz> neutron is still the "preferred" network management layer
15:25:59 <bswartz> we just need to add alternatives
15:26:01 <vponomaryov> bswartz: I guess rushil meant extend neutron support for different types of segmentation
15:26:18 <bswartz> that's a good question
15:26:59 <bswartz> I think we can get around most of the complicated network segmentation issues using cross-tenant share servers/cross-tenant share networks
15:28:03 <bswartz> to address the hardest case, where we still want tenant-specific networks and share servers, and VXLAN/GRE is used, manila will need to be able to create new networks and routers, and that will rely on neutron APIs
15:28:33 <bswartz> honestly that use case isn't high on my list of priorities though
15:28:43 <bswartz> given how many other more common use cases are not served well by the current design
15:30:40 <bswartz> so we don't need to discuss the whole thing here
15:31:02 <bswartz> like I said this will be more complete next week and we'll discuss in paris
15:31:10 <vponomaryov> bswartz: do we expect some "polling" on use cases?
15:31:19 <bswartz> polling how?
15:31:38 <bswartz> I think we have an intuition which are more common and which are less common
15:31:40 <vponomaryov> bswartz: somehow on basis of "do consider this to implement"
15:31:57 <bswartz> we can write down those intuitions in the document -- about how common we think each case is
15:32:32 <rushil1> bswartz: I think apart from the border scenario of simple network plugin, all the other scenarios can be reused from neutron.
15:32:37 <bswartz> my intention is to address ALL of the ones written down unless there's something specific about a particular use case that makes it hard/impossible to implement and we intentionally punt on it
15:32:39 <vponomaryov> bswartz: implementation of some use cases can make code very difficult to support
15:33:05 <bswartz> vponomaryov: can you give the names?
15:33:30 <vponomaryov> bswartz: custom share-servers and mapping of it to manila entity
15:33:51 <bswartz> which use case is that?
15:34:03 <bswartz> I'm just talking about the use cases at the top, not the design changes below
15:34:07 <vponomaryov> bswartz: "How will the share server get imported into Manila? Conf file options? A new admin API?"
15:34:15 <bswartz> okay don't worry about those for now
15:34:54 <bswartz> the design changes will be evaluated by considering how well they address the use cases, plus other considerations like how hard they are to implement/use
15:35:17 <bswartz> I was just referring to the list of use cases -- I hope we can address all of them
15:35:45 <vponomaryov> this is "use case" and it does not fit well our current networking approach
15:36:39 <bswartz> well a number of the use cases demand the ability to take a server that exists outside manila and manage it with manila
15:37:04 <bswartz> we can stipulate all kinds of requirements and prerequisites in order for that to work so that the implementation is not super difficult
15:37:09 <vponomaryov> current design assumes Manila will create share servers
15:37:14 <bswartz> I agree
15:37:33 <bswartz> the proposed change is large, which is why we need to spend some time discussing it
15:37:46 <bswartz> but I don't see a way to argue that it simply shouldn't be done
15:37:55 <bswartz> there are too many situations where it's unavoidable
15:38:14 <bswartz> for example consider glusterfs
15:38:30 <bswartz> glusterfs simply won't be creating share servers -- it uses what exists
15:38:36 <vponomaryov> bswartz: I mean, we can reconsider the approach itself
15:39:03 <vponomaryov> bswartz: but it will be much bigger change then extending existing one
15:39:05 <bswartz> which approach do you want to reconsider? what we currently do now? or something that I've suggested?
15:39:18 <vponomaryov> first one
15:39:25 <vponomaryov> existing
15:39:38 <bswartz> I haven't ruled out the possibility that we may need a whole different driver to support the "manage existing server" use case
15:40:12 <bswartz> ideally a single driver could do both kinds of cases, but I think it's more important to meet user needs than to make developer's lives easy
15:41:03 <bswartz> plus we can always refactor the implementation internally after we're happy with the external interfaces
15:42:33 <bswartz> okay
15:42:40 <bswartz> #topic open discussion
15:42:45 <bswartz> anything else for today?
15:43:07 <bswartz> I've managed to put you all asleep...
15:43:20 <bswartz> we'll have this meeting next week as planned
15:43:32 <bswartz> and obviously the following week is the summit so the IRC meeting is cancelled
15:44:08 <bswartz> #action bswartz by next week present a prioritized agenda for the manila team meetup
15:44:22 <bswartz> we will discuss the meetup topics and priorities next week
15:44:37 <bswartz> csaba: I'll include your suggestion -- thanks
15:44:55 <bswartz> okay thanks all
15:45:01 <vponomaryov> thanks
15:45:07 <bswartz> #endmeeting