15:00:18 <bswartz> #startmeeting manila
15:00:19 <openstack> Meeting started Thu Sep 26 15:00:18 2013 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'manila'
15:00:46 <bswartz> good morning / good evening everyone
15:01:03 <yportnova> hi
15:01:06 <caitlin56> hi
15:01:46 <bswartz> the agenda is here
15:01:49 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:02:18 <bswartz> do we have vbelokon?
15:02:30 <yportnova> bswartz: vbelokon is absent today
15:02:43 <bswartz> yportnova: do you have any updates you'd like to share?
15:02:49 <yportnova> I can give status update
15:03:13 <yportnova> The main update is that Manila finally moved to stackforge
15:03:38 <bswartz> yes we're now officially in stackforge and I sent out the announcement about the project on the public ML yesterday
15:04:08 <bswartz> yportnova: there is a bug that remains open I wanted to ask you about
15:04:29 <yportnova> bswartz: could you provide the link?
15:04:53 <bswartz> #link https://bugs.launchpad.net/openstack-ci/+bug/1229151
15:05:32 <bswartz> can we close that bug or do we need to do something?
15:05:44 <yportnova> This is CI bug now
15:06:03 <bswartz> does it affect us though?
15:06:12 <bswartz> I saw that submissions were working
15:06:26 <yportnova> it does not affect us any more
15:06:36 <bswartz> does it need to stay open though?
15:06:46 <bswartz> If so I'll just unsubscribe
15:07:45 <bswartz> #topic Networking
15:07:46 <yportnova> It need to stay open for CI team. They propably need to fix it. You can just unsubscribe
15:08:01 <bswartz> okay so the next thing I wanted to talk about is networking
15:08:09 <bswartz> this is the big design issue that everyone talks about
15:08:21 <bswartz> #link https://wiki.openstack.org/wiki/Manila_Networking
15:08:53 <bswartz> I've taken the documents and email threads that we have on this topic and tried to distill them into a single wiki that captures all of the issues we know about
15:09:10 <bswartz> I don't expect you to read it right now
15:09:50 <bswartz> but I'm looking for feedback on this if anyone reads it and sees a problem or omission
15:10:25 <bswartz> one of the next activities for me and the dev team is to devise an API design that allows us to address these problems in Manila
15:10:47 <rushiagr> hi all! sry, late :/
15:10:48 <caitlin56> I'd like to suggest a goal. We should treat this as a network proposal at the IETF. We should explicitly state all of the Security Considerations.
15:10:54 <bswartz> rushiagr: welcome
15:11:14 <caitlin56> In particular, when is the flat model applicable?
15:11:37 <bswartz> caitlin56: I'm not sure how much formality we'll be able to achieve
15:11:45 <bswartz> caitlin56: we're a bunch of hackers after all
15:11:51 <bswartz> lol
15:12:16 <bswartz> certianly there are security concerns, but it's hard to evaluate them in the absence of an actual design
15:12:19 <caitlin56> But you are making recommendations to customers. Without saying anything you imply that the option is safe to use.
15:12:34 <bswartz> caitlin56: no -- we're not even close to being able to recommend things to customers
15:12:49 <bswartz> we have to design the API that will allow the things I mention in the document to be implemented
15:12:58 <caitlin56> But completing the design would have to include that, in my opinion.
15:13:23 <bswartz> yes once we have a design, we can evaluate it for security concerns before we get too far down the implementation path
15:13:46 <bswartz> this document is more of a statement of the problem and some possible ways to solve it
15:14:49 <bswartz> yportnova: you and I should spend some time talking about possible API designs, then I can publish another document for the group to review
15:15:11 <yportnova> bswartz: ok, sure
15:15:24 <bswartz> at this point I'm mostly curious to know if I'm missing anything obvious in the problem statement itself, or if I'm missing any really cool solution ideas
15:15:26 <rushiagr> can someone give me the link to the document, if it exists?
15:15:36 <bswartz> rushiagr: https://wiki.openstack.org/wiki/Manila_Networking
15:15:45 <rushiagr> bswartz: thanks
15:16:30 <bswartz> since attendence is light today, I'm going to put a link to this wiki on the LP too
15:16:38 <caitlin56> My current evaluation is that we don't have a good enough method for tenants to edit ACLs in the flat model.
15:16:50 <bswartz> and we can try to keep discussion captured on LP or the wiki
15:16:57 <yportnova> bswartz: I have looked through this document, network plumbing seems the good option
15:17:13 <yportnova> possible solution could be adding creating external network with the storage and adding it to neutron tenant's router.
15:17:27 <yportnova> So tenant VMs can connect to the storage through external net with router's IP (unique for tenant).
15:17:41 <bswartz> caitlin56: the flat model is only intended for people that are doing things we never anticipated, or things where ACLs don't matter so much
15:17:42 <yportnova> In such case we can implement IP based security.
15:17:53 <caitlin56> yportnova: I agree the neuton model seems solid.
15:18:30 <bswartz> so I added a section to the document recently that I forgot to include yesterday about plugins
15:18:35 <caitlin56> bswartz: agreed, with a proper applicability statement it is still a valuable addition to the toolset.
15:18:46 <bswartz> in case it's not clear, I want to implement ALL of these methods, and allow the administrator to choose which one they use at runtime
15:19:28 <bswartz> I realize that implementing all of the methods will likely place a bigger burden on backend authors
15:19:32 <caitlin56> I suspect supporting one tenant on both models would be a nightmare.
15:19:55 <bswartz> so I want to try to find a way to share code as much as possible between backends w.r.t. the various ways to hooking up the shares on the network
15:20:16 <bswartz> caitlin56: yeah I envision a global flag in manila.conf
15:20:20 <yportnova> bswartz: It could be the problem that network in tenants can overlap
15:20:48 <bswartz> yportnova: I have not considered overlapping tenants
15:21:02 <bswartz> yportnova: I'm not even sure that's possible in OpenStack
15:21:09 <caitlin56> One area where there can be no overlap is the ability of a tenant to use their existing AD/
15:21:14 <caitlin56> LDAP authentication server.
15:21:20 <yportnova> bswartz: it is possible in Neutron
15:21:29 <caitlin56> Users do not want to modify their existing Authentication Servers.
15:21:35 <bswartz> yportnova: okay that's a possible problem we need to consider then
15:22:27 <bswartz> I'm not sure if we will manage to solve all of these problem in the IceHouse timeframe either
15:22:30 <vbellur> bswartz: maybe a configuration to allow/disallow overlapping tenants?
15:23:02 <bswartz> We need to prioritize the tasks so that by the end of IceHouse we have something reasonably useful even if it doesn't address every single use case
15:23:23 <bswartz> vbellur: I was thinking that maybe in in the short term just disallow it altogether
15:23:32 <bswartz> we'll need to think about it however
15:23:40 <vbellur> bswartz: right
15:24:05 <bswartz> okay so expect more conversations about this stuff
15:24:31 <caitlin56> vebellur: how do overlapping tenants even work?
15:24:44 <bswartz> the networking problems are the "fun stuff" (i.e. hard problems) for the Manila project and I'm sure there will be discussion ongoing for a long time
15:25:01 <bswartz> for now though let's move on
15:25:15 <bswartz> #topic summit sessions
15:25:30 <bswartz> rushiagr: you put a topic on the agenda, what did you want to say about this?
15:26:09 <vbellur> another qn - how many of us are going to be in Hongkong?
15:26:24 <rushiagr> I just wanted to have a design session for Manila at the Summit
15:26:42 <rushiagr> so just wanted to check if anyone has already proposed/wanted to propose
15:26:44 <caitlin56> I'm planning on it, but the official budget is undecided so far.
15:27:18 <bswartz> okay so my plan has been to hold at least one "unconference" session for Manila
15:27:25 <vbellur> caitlin56: ok, I intend being there.
15:27:34 <bswartz> I'll be in HK, along with a group of other NetApp folks
15:27:45 <bswartz> I'm sure we won't get any official time given our current status
15:27:50 <rushiagr> rushiagr: I'll most probably make there too
15:27:59 <bswartz> however unconference sessions are intended for exactly this kind of thing
15:28:22 <vbellur> right
15:28:49 <bswartz> I expect the purpose of the session will be mostly to meet and greet people interested in Manila so we can have some face-to-face interactions before we all go home and code for 6 months
15:28:50 <rushiagr> bswartz: but lets atleast propose a session?
15:29:02 <bswartz> if we can get 2 sessions then maybe we can actually get into some real design work though
15:29:23 <bswartz> rushiagr: proposed sessions need to be associated with a project I believe
15:29:37 <bswartz> design summit sessions, that is
15:29:48 <rushiagr> bswartz: oh, yeah
15:29:54 <bswartz> conference sessions are more open, but those are closed now
15:30:00 <bswartz> open in terms for format
15:30:39 <caitlin56> Is there still a "birds-of-a-feather" track scheduled?
15:30:55 <bswartz> after we befome an officially incubated project we will have some standing to request official time on the design summit calendar
15:31:48 <bswartz> so the official plan is that I'll setup 1 or 2 unconference sessions, scheduled to not overlap with anything storage-related
15:31:57 <bswartz> and we'll try to meet up there
15:32:09 <rushiagr> bswartz: +1
15:32:14 <vbellur> bswartz: +1
15:32:26 <bswartz> #topic open discussion
15:32:40 <bswartz> anyone have anything else?
15:32:58 <vbellur> i will be on vacation for the next 2 weeks. so I will be missing the next 2 meetings.
15:33:05 <rushiagr> I've seen people merging sessions for dearth of time, so proposing two sessions wont hurt much
15:33:39 <vbellur> rushiagr: agree
15:33:42 <rushiagr> I'd probably test out the brand new manila project, and file all sorts of bugs as a starter
15:33:46 <bswartz> rushiagr: I know -- as the project gets bigger it's harder and harder to cram everything into 4 days
15:33:58 <caitlin56> Don't try for more than 2 sessions though. I suspect a lot of us also have to cover Cinder or Swift.
15:34:05 <bswartz> rushiagr: thanks
15:34:26 <rushiagr> thats my plan for the coming week
15:34:35 <bswartz> caitlin56: I agree -- personally I'll be in all the cinder sessions so there's no chance of a conflict there
15:35:18 <bswartz> if anyone has suggestions for things to avoid conflicting with I'll try to respect those
15:35:30 <bswartz> obviously some of us have intereste in swift and neutron
15:35:50 <bswartz> and nova often has storage-related talks that are worth attending
15:35:59 <caitlin56> And scheduling so neutron folks could attend would be a plus.
15:36:43 <bswartz> okay so it sounds like that's all for this week
15:36:55 <bswartz> look for more information on the networking stuff as I have time to add to the wiki
15:37:02 <bswartz> I'll put some information in BP form on the LP as well
15:37:20 <vbellur> sounds good
15:37:49 <bswartz> please direct feedback to the LP or wiki pages if you want to keep the discussion public
15:38:03 <rushiagr> bswartz: sure
15:38:06 <bswartz> you can email me but my time is pretty crunched so I rather keep everything public
15:38:19 <bswartz> thanks everyone see you next week
15:38:30 <bswartz> #endmeeting