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