15:01:22 <bswartz> #startmeeting manila
15:01:23 <openstack> Meeting started Thu Sep 11 15:01:22 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:26 <openstack> The meeting name has been set to 'manila'
15:01:41 <bswartz> hello folks
15:01:42 <cknight> Hi
15:01:43 <bswartz> who's here
15:01:46 <vponomaryov> hi
15:01:50 <csaba> hi
15:02:05 <xyang1> hi
15:02:05 <deepakcs> hi
15:02:07 <rushil> hi
15:02:17 <AlkaD> hello
15:02:25 <bswartz> so I've been doing a lot of reading about neutron in the last week
15:02:30 <scottda> hi
15:02:42 <bswartz> trying to figure out how to clearly explain networking to people
15:02:49 <deepakcs> bswartz, nice
15:03:05 <bswartz> deepakcs: don't say that until you see the mess that came out of it
15:03:09 <scottda> hehe
15:03:16 <deepakcs> bswartz, ah ok i thought u will help clear it ;-)
15:03:23 <bswartz> I'm going to try to clear it up
15:03:45 <bswartz> but there are something I've been ignoring and they might be real problems
15:03:55 <deepakcs> ok
15:03:55 <bswartz> we will talk about them when we reach that part of the agenda
15:04:00 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:04:03 <TriV|3> hi
15:04:28 <bswartz> so the first topic, very important is
15:04:33 <bswartz> #topic bugs
15:04:56 <bswartz> right now the team focus is on getting a stable juno release done
15:05:15 <bswartz> as I mentioned last week, no new features will be accepted
15:05:37 <bswartz> and bugfixes will only be accepted if they have a bug in LP targetted at juno-rc1
15:06:33 <bswartz> if you have a bug you think needs to be targeted to juno-rc1, please talk to a core team member
15:06:39 <deepakcs> bswartz, so when we open a bug. how do we set the target.. currently i bug valeriy
15:06:45 <deepakcs> ok :)
15:06:46 <bswartz> I see 8 bugs still open
15:06:52 <bswartz> yeah you need a core team member to target it
15:07:05 <bswartz> if anybody could target bugs it would be chaos
15:07:15 <deepakcs> make sense
15:07:19 <bswartz> actually 9 open bugs
15:07:24 <xyang1> bswartz: unfortunately launchpad doesn't prevent that
15:07:30 <bswartz> what?!?
15:07:45 <bswartz> xyang1: think it does
15:07:48 <xyang1> bswartz: I mean I think anyone can set the target there
15:07:59 <xyang1> bswartz: is it?  I'll double check
15:08:12 <bswartz> xyang1: I can't target cinder bugs
15:08:31 <xyang1> bswartz; ok, I'll check that again.
15:09:03 <bswartz> okay and we're down to 14 days until the release candidate is expected
15:09:21 <bswartz> top priority is closing the remaining 9 bugs
15:09:44 <bswartz> and the sooner we find out about any new bugs that have to be fixed in juno the better
15:10:11 <bswartz> any questions on bugs, or any requests to target a bug right now?
15:10:47 <bswartz> okay cool
15:10:57 <AlkaD> one quick question
15:10:57 <bswartz> #topic development status
15:11:01 <bswartz> ack
15:11:02 <bswartz> #undo
15:11:03 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2af6f90>
15:11:12 <bswartz> AlkaD: go ahead
15:11:14 <AlkaD> are all the bugs being worked on at this time
15:11:16 <AlkaD> ?
15:11:25 <AlkaD> open 9 bugs?
15:11:37 <bswartz> AlkaD: yes they all have owners, and most of them are marked in progress
15:11:43 <AlkaD> thanks
15:11:49 <bswartz> lgreg owns 3 of them
15:11:51 <AlkaD> I am new, trying get involved
15:12:05 <AlkaD> new on Manila
15:12:11 <bswartz> I'll ping him to make sure he's making progress on the 3 he owns
15:12:20 <bswartz> welcome AlkaD!
15:12:37 <bswartz> okay....
15:12:40 <bswartz> #topic development status
15:12:44 <vponomaryov> Dev status for last week:
15:12:52 <vponomaryov> 1) Manilaclient now can handle names for security services operations.
15:12:56 <vponomaryov> 2) Share networks and security services now can be updated more properly.
15:13:00 <vponomaryov> 3) Other attempts were directed to testing and bugfixing, available for review:
15:13:19 <vponomaryov> 3.1) #link https://review.openstack.org/120712
15:13:19 <vponomaryov> 3.2) #link https://review.openstack.org/119621
15:13:19 <vponomaryov> 3.3) #link https://review.openstack.org/120711
15:13:39 <vponomaryov> that's the main
15:13:59 <bswartz> is vlad here?
15:14:31 <bswartz> I see some -1 on his changes so I hope he's watching and addressing those
15:14:32 <TriV|3> yes
15:14:43 <TriV|3> I'm here)
15:14:44 <vponomaryov> bswartz: yes, it will be fixed soon
15:15:01 <bswartz> TriV|3: oh hi -- I didn't recognize your irc handle
15:15:17 <bswartz> okay
15:15:27 <bswartz> so on to the fun stuff
15:15:41 <bswartz> #topic terminology
15:16:05 <bswartz> we've been talking about the concept of single-tenant/multi-tenant drivers (please DON'T use those terms)
15:16:19 <bswartz> we've been talking about the concept of flat-network drivers and non-flat-network drivers
15:16:48 <bswartz> and there's confusion all around
15:17:03 <bswartz> I think part of it is my fault, because I've been making some oversimplifying assumptions
15:17:54 <bswartz> so I spent some time thinking carefully about all the use cases and learning as much as I could about neutron and nova-net and various real storage controllers
15:18:18 <bswartz> I threw together this wiki page which is rambling and disorganized
15:18:19 <bswartz> #link https://wiki.openstack.org/wiki/Manila/Networking
15:19:15 <bswartz> the first thing I want to point it is that "flat-network driver" was really not a good term either
15:19:24 <bswartz> it's almost as bad as single-tenant
15:20:20 <bswartz> the real interesting difference in driver styles is whether a driver is capable of creating virtual share-servers or not
15:20:38 <bswartz> and the line is actually a bit blurry
15:21:28 <bswartz> so what that wiki page attempts to do is list the various choices and issues that openstack admins have to wrestle with
15:21:33 <csaba> virtual share server == service vm?
15:21:49 <bswartz> csaba -- yeah pretty much
15:22:02 <bswartz> although certain vendors may have a different name
15:22:33 <bswartz> my goal is to boil down all the complexity to what choices we need to concern ourselves with inside manila
15:22:53 <bswartz> I tried to write a flowchart and that got too complicated
15:22:58 <Shamail> Hi Ben, is the ability to create virtual share-servers or not the delimiter or whether the real storage controller can connect to multiple networks (e.g. VLAN tagging or network overlay support)?  The ability to create share-servers is not a network support attribute.
15:23:11 <bswartz> so I came at it from the other side
15:23:27 <bswartz> Shamail: no it's not that simple, that's why I said the line is blurry
15:24:13 <bswartz> certainly the ability to create SVMs or share-servers allow you to do things more securely, but it's not a single deciding factor
15:24:45 <bswartz> the work the redhat guys are doing, and what several customers are doing is forcing me to think about things differently
15:25:08 <bswartz> if you jump down to the bottom of that wiki I tried to write my conclusion
15:25:21 <bswartz> we need to support things other than neutron, basically
15:25:27 <bswartz> too many customers are still using nova-network
15:26:01 <bswartz> and for small installation on a lab for development or POC purposes, we need something that will work with no network infrastructure whatsoever
15:26:24 <xyang1> bswartz: Isn't there effort trying to move from nova-network to neutron?
15:26:42 <bswartz> xyang1: absolutely
15:26:55 <vponomaryov> xyang1: we should not force them to do it
15:27:03 <vponomaryov> xyang1: by manila restriction
15:27:03 <bswartz> honestly I'm not sure what's holding customers back -- I've heard different things
15:27:29 <bswartz> but what vponomaryov says is exactly right: we shouldn't be pushing them one way or the other
15:27:40 <bswartz> we should simply try to work with what they want to use
15:27:44 <deepakcs> bswartz, what do you mean by "support things other than neutron" - an example may help
15:27:59 <vponomaryov> deepakcs: nova-network
15:28:04 <bswartz> deepakcs: specifically, we need to write a nova-network plugin
15:28:06 <xyang1> I'm just not sure how long nova-network will exist, but doesn't look like it is going away soon
15:28:17 <bswartz> and we need to write a "simple" plugin that has very light requirements
15:28:53 <bswartz> and we may want to write a more interesting plugin that has some powerful capabilities that don't depend on neutron or nova-net
15:29:11 <csaba> plugib
15:29:12 <bswartz> that last one I'd rather leave for customers or users to write, but it's not impossibe for us to take on
15:29:35 <csaba> plugin to what exactly?
15:29:51 <bswartz> so manila has a network plugin architecture already
15:29:57 <bswartz> with only 1 plugin (neutron)
15:30:07 <rushil> csaba: plugin to remove dependance on neutron
15:30:33 <vponomaryov> rushil: plugin to extend support coverage
15:30:50 <AlkaD> bswartz: I liked your plan at the end of the wiki
15:30:53 <bswartz> the idea is the abstract out all of the requirements manila has on neutron into something that can be replaced by end users
15:31:06 <csaba> rushil: I was not aware of network pluggability
15:31:09 <bswartz> that has been done
15:31:11 <rushil> vponomaryov: That too
15:31:26 <bswartz> now what's needed is to provide some more alternatives to make developers and customer's lives better
15:31:36 <AlkaD> +1
15:32:01 <bswartz> and briefly, I'd like to call attention to some other deployment scenarios that I thought about
15:32:56 <bswartz> so the gold standard is the scenarios where the manila backend creates at least one share server for every tenant, and they're all on private networks where the network layer can enforce security
15:33:34 <bswartz> and there is the case of a relatively flat network where a single large share server can be shared by all the tenants
15:33:47 <bswartz> but there are shades of grey between these
15:34:25 <bswartz> such as perhaps a netapp controller on a lab network, where multiple SVMs can be created, but not on different vlans
15:35:16 <bswartz> we've been moving toward this case with the "default share network" stuff we've been talking about, but only in the last week did I realize that it's a different case
15:35:43 <bswartz> so we're getting a bit off track here because we're talking about design and features for Kilo
15:35:58 <bswartz> getting back to terminilogy
15:36:28 <bswartz> I've decided flat-network is not a useful term given all the different configs that are possible
15:36:51 <bswartz> I still don't have a good way to classify the different types of drivers
15:37:04 <bswartz> and my current feeling is that maybe we shouldn't try to classify them
15:37:25 <bswartz> maybe it's better to leave the shades of grey alone and to write about specific deployment scenarios and how to achieve them
15:37:49 <bswartz> the neutron docs show excellent examples of that
15:38:12 <bswartz> neutron is fabulously complex but the docs spell out some very easy to understand scenarios
15:38:43 <bswartz> so +1 for the neutron doc writers -- we should try to emulate them
15:38:51 <bswartz> with our own docs
15:39:12 <bswartz> does anyone think I'm off track here by dodging this terminology question?
15:39:15 <AlkaD> yeah terminology can be tricky
15:39:51 <xyang1> no, I think it is good to talk about terminology
15:39:57 <AlkaD> so you are lookig for terms to describe shades of grey
15:40:16 <scottda> The strategy of spelling out specific scenarios sounds like the way to go.
15:40:19 <vponomaryov> bswartz: it is useful, but I do not agree that we should live shadows on drivers difference
15:40:19 <bswartz> xyang1: do you think we still need to come up with names for the different types of drivers?
15:40:43 <bswartz> we will need to describe what certain drivers can and can't do
15:40:48 <deepakcs> bswartz, +1 IIUC you are saying we should write good docs that go about what kind of networking to use for what kind of problem/deployment ?
15:40:52 <xyang1> bswartz: what you have planned sounds good to me.  don't have to come up with names for different types of drivers
15:40:53 <rushil> I think we need to define it on a per driver basis
15:40:54 <bswartz> but it will end up looking more like a compatibility matrix I think
15:41:31 <bswartz> for different types of drivers there will be different things to consider
15:41:48 <bswartz> for example, the generic driver has NO dependence on why type of physical switch infrastructure you have
15:42:11 <bswartz> but the netapp driver relies heavily on having a physical switch with VLAN trunk ports
15:43:08 <bswartz> deepakcs: I'm saying I don't want to divide everything into 2 categories or even 3
15:44:05 <bswartz> the exactly list of capability differences is still TBD
15:44:24 <bswartz> okay enough on that topic
15:44:35 <bswartz> please provide feedback on the wiki page if you like
15:44:45 <bswartz> it's a work in progress
15:44:48 <bswartz> we have other topics
15:44:56 <bswartz> #topic juno release plan
15:45:15 <bswartz> so I already mentioned the target RC1 date of Sept 25
15:45:43 <bswartz> I want to talk to distro vendors about what are the requirements to produce debs/rpms for manila after the official juno release
15:46:06 <bswartz> anyone from redhat/suse/canonical here?
15:46:18 <bswartz> who works on distribution?
15:46:41 <deepakcs> i am from redhat, but don't work on the distro side
15:46:46 <bswartz> I have the list of maintainers I can follow up with
15:46:55 <xyang1> eharney may know about packaging
15:47:03 <deepakcs> I can try to get help in case u dont get thru your regular channels, let me know
15:47:47 <bswartz> zaitcev is the redhat guy I need to speak with and I don't see him here
15:48:19 <bswartz> anyways after RC1 I'll be working with distro vendors to produce packages
15:48:43 <bswartz> I'm pretty sure most of the distro vendors will be putting manila-related packages into "development" or "tech preview" type repos
15:49:02 <bswartz> but having packages will greatly simply the lives of customers
15:49:27 <nileshb> tentatively when do we expect to get manila packages for distros like redhat?
15:49:57 <bswartz> nileshb: not before Oct 16
15:50:02 <nileshb> would we be creating manila rpms?
15:50:31 <bswartz> Oct is the official release date so I don't expect anything official to happen until after that
15:50:47 <bswartz> but we'll be working with distros to make manila rpms absolutely
15:51:01 <nileshb> thanks
15:51:04 <bswartz> so there's the question of icehouse compatibility
15:51:26 <bswartz> customers currently have icehouse, and many won't upgrade to juno until months after the release
15:51:44 <bswartz> we never made an official icehouse release and never created a stable/icehouse branch
15:52:24 <bswartz> however there is some value in having something like that and building rpms/debs based on that too
15:52:43 <AlkaD> I agree
15:52:57 <bswartz> the icehouse-compatible version of manila would contain all of the changes from Juno most likely because there are too many bugs that have been fixed to not include them
15:53:13 <nileshb> are we going to create such a branch (stable/juno) for Juno (probably I am out of sync on this)
15:53:33 <vponomaryov> bswartz: there are only one dependency restriction - manila uses external packages of versions that appeared only in juno
15:53:35 <bswartz> yes there will absolutely be a stable/juno branch when kilo opens up
15:53:52 <rushil> vponomaryov: +1
15:54:01 <bswartz> vponomaryov: yeah I think we may need to work with distro vendors on how to address those
15:54:22 <bswartz> possibly the manila rpms will just have a bunch of extra dependencies
15:54:32 <vponomaryov> bswartz: some virtualenv for Manila should fix it
15:54:38 <bswartz> as long as they don't conflict I don't see a huge problem
15:55:16 <bswartz> so that's something we will figure out in the next few week as well
15:55:28 <bswartz> any questions on that?
15:55:40 <bswartz> we've got 5 minutes left for anything I missed
15:55:44 <bswartz> #topic open discussion
15:55:45 <xyang1> bswartz: what are we doing with documentation?
15:56:13 <vponomaryov> xyang1: good catch =)
15:56:13 <bswartz> xyang1: read annegentle's manila ML post if you haven't
15:56:20 <deepakcs> when do we move from stackforge to openstack git repos ?
15:56:41 <vponomaryov> deepakcs: infra guys postponed it to weekend after this one
15:56:46 <bswartz> we can't write docs for openstack-manuals YET, but we can put the content into manila/docs
15:57:02 <deepakcs> vponomaryov, ok
15:57:24 <bswartz> rushil is working on making the doc updates
15:57:24 <atiwari> woodster, yt?
15:57:57 <vponomaryov> bswartz: I was thinking what if we add image requirements for generic driver to our docs?
15:57:59 <bswartz> and when we have the content written we'll work with the docs folks to find a home for it somewhere on docs.openstack.org
15:58:05 <vponomaryov> bswartz: docs in manila repo
15:58:20 <bswartz> vponomaryov: yes, we should add everything we can think of
15:58:33 <bswartz> I'll make a checklist of things for next week
15:58:35 <vponomaryov> bswartz: is it kilo only?
15:58:44 <bswartz> no it's for Juno
15:58:51 <vponomaryov> bswartz: ok
15:59:01 <bswartz> we want users of the juno release to have good docs that explain how to set it up and how to use it
15:59:13 <AlkaD> +1
15:59:14 <bswartz> but top priority is still bugs
15:59:15 <xyang1> we should have a section for each driver in the doc as well
15:59:19 <vponomaryov> bswartz: not everything at once =)
15:59:23 <bswartz> bugs first, docs second, and kilo features third
16:00:18 <bswartz> xyang1: go ahead and contribute a doc on configuration for the EMC driver
16:00:40 <bswartz> we're at the end of our time
16:00:51 <bswartz> thanks everyone
16:00:54 <AlkaD> thank you
16:00:55 <xyang1> bswartz: sure, if rushil can tell me the location.  will ping him later
16:00:55 <vponomaryov> thanks
16:00:55 <rushil> bye
16:00:59 <xyang1> thanks
16:01:03 <bswartz> #endmeeting