15:04:52 <bswartz> #startmeeting manila
15:04:53 <openstack> Meeting started Thu Dec 19 15:04:52 2013 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:57 <openstack> The meeting name has been set to 'manila'
15:05:11 <bswartz> there we go
15:05:26 <bswartz> I don't know what's up w/ the but but hopefully it will record our meeting
15:05:33 <bswartz> s/but/bot/
15:05:34 <markwash> okay, looks like all is well now, have a nice day manila
15:05:40 <bswartz> ty markwash
15:05:57 <bswartz> #topic holidays
15:06:14 <bswartz> okay so before I forget, let's talk about the upcoming meetings
15:06:41 <bswartz> I'll be on vacation the next 2 weeks and am not able to chair these meetings
15:07:00 <bswartz> is there any interest in holding them without me?
15:07:19 <bswartz> would someone like to volunteer to chair them in my absence?
15:07:23 <akerr1> wouldn't be the same without you
15:07:51 <caitlin56> What's the likelihood of major status updates 2 weeks from now?
15:08:07 <bswartz> akerr1: The project shouldn't revolve around me though
15:08:27 <bswartz> well I expect that progress will be relatively modest in the next 2 weeks
15:08:43 <caitlin56> Not much point in debating things 2 weeks from now, but we might want some form of progress announcement before 3 weeks go by.
15:08:56 <bswartz> unless someone tells me that they're not taking time off and they plan to spend all their time working on manila!
15:09:45 <caitlin56> How about , "if you make major progress over the next 2 weeks, announce it on the mailing list rather than waiting for the third week."
15:10:03 <bswartz> okay so the silence tells me there's no appetite for IRC meetings, which is fine by me
15:10:22 <bswartz> consider the 26 Dec and the 2 Jan meetings cancelled
15:10:33 <bswartz> we'll meet next on 9 Jan
15:10:51 <shamail> bswartz: Sounds good
15:10:51 <bswartz> #topic development status
15:11:19 <bswartz> I've seen lots of activity with the code reviews
15:11:32 <bswartz> I'll admit that I haven't been able to spend the time I'd like to on code reviews
15:12:20 <bswartz> yportnova, vponomaryov: any updates from the last week?
15:12:46 <bswartz> vponomaryov: any updates from the last week?
15:13:37 <vponomaryov> hi
15:13:40 <bswartz> erm, maybe they're not here
15:13:54 <gregsfortytwo> lol
15:14:02 <bswartz> doh
15:14:03 <bswartz> sorry about that
15:14:16 <gregsfortytwo> switch windows; don't close them ;)
15:14:27 <bswartz> I think i clicked too many times
15:14:46 <achirko> bswartz: https://review.openstack.org/62917 and https://review.openstack.org/60241 ready for code review
15:14:49 <vponomaryov> about netapp driver: it is not finished yet, not so long we got lab with backend in l2 layer
15:15:12 <bswartz> The neutron plugin went in
15:15:41 <bswartz> we're close to having a driver that supports the full multitenancy model
15:15:45 <vponomaryov> about network-api - ready for review
15:16:24 <bswartz> thanks achirko, vponomaryov
15:16:36 <bswartz> just a reminder: https://review.openstack.org/#/q/manila+status:open,n,z
15:16:47 * bswartz reminds himself too
15:16:57 <vponomaryov> manila client was a little bit enhanced
15:17:02 <bswartz> okay
15:17:12 <vponomaryov> https://review.openstack.org/#/q/project:stackforge/python-manilaclient,n,z
15:17:33 <bswartz> csaba: are you here?
15:17:48 <csaba> bswartz: hi!
15:18:05 <bswartz> csaba: what is the state of glusterfs driver?
15:18:50 <csaba> we are working on unit tests... we got a bit lag with that with the sudden swicth from mox to mocks
15:19:10 <bswartz> yes
15:19:13 <bswartz> mock is better though
15:19:25 <vponomaryov> bswartz: we have one open item - do we expect, that in one tenant can be more that one set of policy data for security services?
15:19:44 <bswartz> vponomaryov: yes
15:19:45 <vponomaryov> s/that/than
15:20:05 <bswartz> vponomaryov: there are valid use cases for 2 different krb5/ldap domains within one tenant network
15:20:17 <bswartz> or 2 different AD domains within 1 network
15:20:35 <bswartz> I expect those cases to be rare, but not impossible to create
15:20:48 <vponomaryov> bswartz: thanks
15:20:56 <caitlin56> The hard part is supporting multiple Security Domains, multiple tenants is not much more than that.
15:21:27 <bswartz> caitlin56: it comes down to whether backends will be expecte to associate more than 1 "virtual server" with each tenant or not
15:21:37 <bswartz> I say yes
15:21:46 <bswartz> although the common cases will be 0 or 1
15:22:26 <caitlin56> I suppose in a single tenant environment you could trust the two AD servers to not interfere with each other.
15:22:55 <bswartz> caitlin56: it's up to the tenant to not screw up his configuration
15:23:15 <bswartz> all manila does it what the tenant asks for
15:23:26 <bswartz> s/it/is/
15:23:43 <bswartz> okay enough on status
15:23:56 <vponomaryov> bswartz: after your answer about amount of policies
15:24:07 <vponomaryov> appears one more question
15:24:10 <bswartz> we have a lot of open reviews so I'll try to get stuff that's complete merged before the holidays
15:24:33 <vponomaryov> policies and network data can be splitted to two entities in that case
15:25:23 <bswartz> vponomaryov: well each network can have 0 or more policies associated with it, each one will have a UUID associated with it, and the UUID is what matters when you call share-create
15:26:05 <vponomaryov> UUID of network data?
15:26:44 <bswartz> yes
15:26:56 <bswartz> err, I think
15:27:25 <vponomaryov> but two entities should have its own UUIDs, and one can have link to another
15:27:37 <achirko> bswartz: so as I understand we associate multiple policies with one network, on share-create we specify network_id and policy_id
15:28:10 <vponomaryov> achirko: +1
15:28:15 <bswartz> achirko: no I don't think so
15:28:37 <achirko> bswartz: and if specified policy is not associated with specified network - its an error
15:28:38 <bswartz> I'd rather just have 1 UUID passed to share-create, and that should be the ID of the network info
15:28:57 <bswartz> a given "network" should be able to have more than 1 network info associated with it
15:29:07 <bswartz> 1 per policy
15:29:39 <caitlin56> bswartz: with single tenant, multiple security domains, the tenant domain can export *anything* to any security domain. Correct? With multi-tenant we have to add the restriction that a tenant admin can only export their own stuff.
15:31:04 <bswartz> caitlin56: don't get create and export mixed up
15:31:15 <bswartz> caitlin56: the create is what cares about the security domain
15:31:25 <bswartz> caitlin56: the export just modifies the security rules around the created thing
15:31:44 <achirko> bswartz: ok, so when I say 'network' and 'network-info' i mean neutron subnet. So if we associate many policies with this 'network' and then pass only uuid of 'network', we can't tell which policy to use
15:32:34 <shamail> bswartz: Are you saying that we should be able to define the same network address space to multiple network IDs and the network ID contains a single policy?
15:33:31 <bswartz> okay so we need to get a bit clearer about terms
15:33:57 <bswartz> we have one document here:
15:34:00 <bswartz> #link https://wiki.openstack.org/wiki/Manila/docs/API-roadmap
15:34:18 <bswartz> I should probably add something to this though because it still doesn't clearly communicate what we're talking about
15:34:35 <bswartz> we have neutron subnets, which are defined outside of manila
15:34:51 <bswartz> manila can associate 0 or more policies with each neutron subnet
15:35:06 <bswartz> each of those subnet+policy pairings forms a "network-info"
15:35:14 <bswartz> and that network info has a UUID
15:36:02 <caitlin56> bswartz: you can form a "policy" (what I think of as a "Security Domain") using just export control, you only need neutron networks for multi-tenant. Is that correct?
15:36:15 <bswartz> shamail: I think that it will be clear once we have an implementationg working
15:36:24 <achirko> bswartz: this wiki is outdated - we split 'policy' and 'network' into different APIs
15:36:26 <bswartz> achirko: we may need to follow up on this offline
15:36:41 <bswartz> achirko: do you have any document that's more up to date?
15:37:31 <achirko> bswartz: so docs yes, but we have code
15:37:55 <bswartz> I think a diagram would be worth a thousand words here
15:38:09 <caitlin56> achirko: year-long low on inside-company meeting over the next two weeks -- great opportunity to get doc read.
15:38:11 <bswartz> let's get together and build one
15:38:44 <jcorbin> bswartz: +1
15:39:13 <shamail> I like archirko's suggestion since it sounds more dynamic then pre-configured neutron subnet/policy mappings (e.g. 'Network-info'), but either option seems to achieve similar goals... A) creation of policy and neutron network are split B) binding the two together at same layer
15:39:38 <shamail> doh, IRC was lagging... Discussion has moved on.  Sorry.
15:39:51 <bswartz> speaking of diagrams, I still need to make one that illustrates the multitenancy design, regarding the split between drivers that directly join tenant networks, and drivers that use a bridge/gateway to provide shares to tenants
15:40:14 <bswartz> shamail: IRC lag could explain the bot's odd behaviour earlier
15:40:29 <bswartz> #topic multitenancy
15:41:01 <bswartz> so as I was saying the document here is still out of date (no change from last week)
15:41:46 <bswartz> anyone tried some experiments in this area? either with virtfs or ganesha?
15:42:36 <bswartz> I think I'll start drawing on my whiteboard and taking photographs to create a rough draft of a diagram
15:42:51 * bswartz is not good with graphics authoring tools
15:43:34 <shamail> FS
15:43:48 * caitlin56 volunteers to translate a picture of a whiteboard into a google diagram.
15:44:08 <bswartz> ooh does google have a decent SVG drawing program?
15:44:29 <caitlin56> I don't think it is svg, but same functionality.
15:44:36 <bswartz> very well
15:45:09 <caitlin56> short of what you can do with visio, but without the licensing issues.
15:45:12 <bswartz> okay so this remains a difficult area -- I'd love to see a proof of concept design working
15:45:33 <bswartz> but in the mean time I'll keep working on trying to communicate the design/plan clearly
15:45:40 <bswartz> #topic open discussion
15:45:51 <bswartz> anything else this week?
15:46:10 <bswartz> reminder for those who joined late: meeting is cancelled next 2 weeks, we reconvene on 9 Jan
15:46:35 <bswartz> I will update the wiki
15:46:50 <vponomaryov> bswartz: will you be available via email?
15:47:01 <bswartz> achirko: if you have time on Monday I'd like to finalize the design for network/policy/networkinfo
15:47:25 <bswartz> vponomaryov: off and on -- I will be travelling but I will have my notebook
15:47:34 <achirko> bswartz: ok
15:48:00 <bswartz> okay we'll end a bit early today
15:48:04 <vponomaryov> bswartz; got it, if we have urgent questions, we write
15:48:05 <shamail> Take care everyone, see you after the new year!
15:48:08 <bswartz> thanks everyone
15:48:14 <vponomaryov> thanks
15:48:17 <bswartz> have a safe and happy holiday
15:48:36 <aostapenko> thanks, bye
15:48:42 <achirko> bye
15:48:44 <caitlin56> bswartz: just checked, google draw can export as svg.
15:49:22 <bswartz> #endmeeting