15:01:54 <bswartz> #startmeeting manila
15:01:55 <openstack> Meeting started Thu Jan  9 15:01:54 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:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:59 <openstack> The meeting name has been set to 'manila'
15:02:11 <bswartz> good morning/evening everyone
15:02:13 <caitlin56> morning
15:02:17 <yportnova> hi
15:02:20 <vbellur> hello
15:02:20 <achirko> hello
15:02:22 <aostapenko> evening)
15:02:22 <vponomaryov> hi
15:02:27 <rraja> hi
15:02:30 <csaba> hi
15:02:35 <bswartz> I can't wait until DST starts up again so this meeting can be later in the day
15:02:48 <scottda> hello, and nice to meet you
15:02:57 <bswartz> scottda: welcome!
15:03:11 <scottda> thanks
15:03:23 <xyang1> hi
15:03:36 <bswartz> i hope everyone had an excellent holiday/new year
15:03:53 <bswartz> since we cancelled the last 2 meetings, it's been a while since we met
15:04:04 <vbellur> bswartz: thanks, hope you had a good one too
15:04:39 <bswartz> I had really hoped to have my illustrations/diagrams of manila ready before this meeting but sadly they're still at the stage of being a giant mess on my whiteboard
15:05:41 <bswartz> so that's something I'm working on resolving later today
15:05:41 <bswartz> caitlin56: I got your messages last week and I saw the diagram you drew up
15:05:41 <bswartz> caitlin56: unforatunately I didn't understand it :-(
15:06:25 * caitlin56 volunteers to help with diagrams
15:06:25 <caitlin56> Maybe we can go through it later in the day, or as on open topic.
15:06:29 <bswartz> anyways since the stuff I'm working on isn't ready yet, let's discuss the stuff that is actually going on
15:06:47 <bswartz> caitlin56: I definitely want to discuss with you -- possibly later in this meeting if there is any interest/time
15:07:05 <bswartz> #topic development status
15:07:11 <caitlin56> bswartz: make sense, like you said dealing with already in progress development first makes sense.
15:07:34 <bswartz> yportnova: can you summarize the progress of the last few weeks for the team
15:07:56 <vponomaryov> We have two updates: (1) about network-API and (2) generic multitenant lvm driver
15:07:59 <yportnova> bswartz: sure
15:08:10 <bswartz> vponomaryov: or you can provide the update too
15:08:26 <vponomaryov> 1) https://blueprints.launchpad.net/manila/+spec/join-tenant-network:
15:08:26 <vponomaryov> After testing realese candidate of network-API for manila, we found out, that it has lots of restrictions due to architecture of API.
15:08:36 <vponomaryov> For example, security services used to be set depending on protocol (nfs/cifs), but should be based on security service itself (ad, ldap, kerberos).
15:08:50 <vponomaryov> Also network-info entity used to have only one set of security service, but should be possible to set several, that will be used during share creation, when we choose protocol.
15:09:06 <vponomaryov> So, all of this leads us to change network API.
15:09:06 <vponomaryov> Security service entity prototype described here:
15:09:06 <vponomaryov> https://docs.google.com/a/mirantis.com/document/d/1KIFlOvI_o_641JWIIDIXevuke9IKmun34s4z1VptGPY
15:09:22 <vponomaryov> Then, we will remake network-info to have multiple security-service entities
15:09:22 <vponomaryov> Estimation for this: this and all next weak + testing and bugfixing.
15:09:22 <vponomaryov> After successfull implementation, Manila will have relatively stable API.
15:09:43 <vponomaryov> 2) https://blueprints.launchpad.net/manila/+spec/generic-driver
15:09:59 <vponomaryov> before incubation we need working multitenant generic driver, so this can be separated to 3 (three) parts:
15:09:59 <vponomaryov> - cinder api (DONE) - https://review.openstack.org/#/c/65658/
15:09:59 <vponomaryov> - nova api (TODO: Fast to do basing on cinder api)
15:09:59 <vponomaryov> - driver, that uses methods, which speaks with cinder and nova (TODO)
15:10:42 <vbellur> when we get to an important change in implementation, like changing the API, can we  start communicating on openstack-dev ML?
15:11:10 <bswartz> vbellur: that's a good idea
15:11:38 <bswartz> however I wouldn't want to update the ML until after the change has stabilized
15:11:44 <caitlin56> yponomaryov: how do you associate a share with a security service?
15:12:15 <bswartz> caitlin56: you have to create the "network-info" first
15:12:22 <vponomaryov> caitlin56: security-service -> network-info -> share
15:12:24 <bswartz> caitlin56: and then you specify the ID of that when you create teh share
15:12:51 <bswartz> every share must have a network-info associated with it, even if the network info implies wide-open/no-security
15:12:59 <caitlin56> So each share is part of a "network", each network has one security service?
15:13:21 <vponomaryov> network info can have sec services, but not mandatory
15:13:41 <vponomaryov> for neutron plugin, mandatory are net id and subnet id
15:13:51 <caitlin56> network_info has 0 or 1 security service? or 0..N security services?
15:14:10 <vponomaryov> not 0_1, we plan do it 0_N
15:14:16 <vponomaryov> as for security groups in nova
15:14:25 <vponomaryov> s/not/now
15:14:36 <caitlin56> So then how do you know which security service to use? One per protocol?
15:14:52 <vponomaryov> share creates with protocol
15:15:04 <vponomaryov> for protocol purposes will be choosen sec service
15:15:28 <caitlin56> So there is 0 or 1 security services for each network *and* protocol. right?
15:15:53 <vponomaryov> for now, yes
15:16:05 <jcorbin> Is there a work flow diagram for configuring a share from start to finish?
15:16:39 <bswartz> okay so this is where some documentation and a working example would be helpful
15:16:59 <bswartz> plus i'm not convinced that "network-info" is the best term to use for what these things are
15:17:36 <bill_az_> diagram showing class relationships / cardinality would be helpful
15:17:44 <bswartz> it's very hard to have an intelligent discussion about this stuff if we don't agree on terms
15:17:44 <caitlin56> bswartz: agreed, network-info sounds like the logical network (vlan or whatever).
15:17:53 <caitlin56> bill_az: ++
15:18:00 <jcorbin> bswartz: +1
15:18:18 <bswartz> for now, just understand that network-infos are things that exist in manila, and networks/subnets are things that exist in neutron
15:18:51 <caitlin56> And there can be multiple manila "networks" within a single neutron network, correct?
15:18:51 <vponomaryov> we have choosen network-info, because we should choose some name
15:18:54 <bswartz> manila can associate 0-N network-infos with each subnet in neutron
15:19:07 <bswartz> and each share has exactly 1 network-info
15:19:23 <vponomaryov> caitlin56: yes
15:20:09 <caitlin56> What you are enabling is the mappping of a corporate intranet that has one network but different windows domains (one for HR, one for Engineering, etc.)
15:20:14 <bswartz> caitlin56: actually a VLAN corresponds to a neutron subnet
15:20:33 <bswartz> we could in principle have several network-infos for a single VLAN or subnet
15:20:59 <vponomaryov> yes, but it is not good in architecture view
15:20:59 <bswartz> imagine 2 AD domains running on the same subnet
15:21:20 <caitlin56> Everyone in a manila-network uses the same security servcie to access shares (for a given protocol).
15:21:56 <bswartz> caitlin56: I'm not sure that's true
15:22:43 <bswartz> in my above example (2 AD domains) you could have 2 vservers on the same subnet for a single tenant -- 1 part of each AD domain
15:22:49 <caitlin56> bswartz: that's what I'm trying to nail down. What's the wildest configuration a customer can throw at me that I'll be expected to support.
15:23:30 <bswartz> I ultimately expect that network-infos and vservers will correlate more or less 1-to-1
15:23:31 <caitlin56> But aren't those 2 separate AD domains a "manila-network"?
15:23:40 <bswartz> exceptions will exist in 2 cases that I can imagine:
15:23:58 <bswartz> 1) if a vserver runs out of space and a second one is needed for capacity reasons
15:24:10 <vponomaryov> caitlin56: it is manila-network with two security services
15:24:28 <vponomaryov> in view of entities in manila
15:24:38 <bswartz> 2) if vservers can be shared across 2 networks because the security settings for those 2 networks are "equivalent" insofar as the backend can tell
15:24:41 <caitlin56> yponomaryov: then wouldn't you have to specify the security service for each share?
15:25:27 <vponomaryov> caitlin56: ids of security services should be linked into netwrok-info entity
15:25:31 <caitlin56> That's what I presumed in advance, but you wanted to hang this off of the manila-network.
15:25:31 <bswartz> caitlin56: I think you're using words that we don't have an agreed definition for
15:25:38 <bswartz> what do you mean when you say manila-network?
15:26:21 <caitlin56> The set of file servers and clients that share common security.
15:26:53 <caitlin56> My assumption had been that this was not an object, that you specified the security service for each share. But you said that was not the case. So I'm trying to understand the rules.
15:27:42 <bswartz> the network-info is the object inside manila that contains all this info
15:27:57 <bswartz> network-infos are actually rows in a table, each one has an ID and a bunch of metadata
15:28:20 <bswartz> The API vponomaryov mentioned manages these new objects
15:28:32 <caitlin56> bswartz: so "network-info in manila context" probably should 'manila' as part of its name. Otherwise folks will get confused vs neutron defined networks.
15:28:51 <bswartz> caitlin56: I agree the name is confusing
15:29:18 <bswartz> caitlin56: my concern with the term "manila-network" is that I don't want to give people the impression that manila is managing networks (ala nova-network)
15:29:33 <vponomaryov> bswartz: +1
15:29:35 <bswartz> we need a better name
15:29:50 <vponomaryov> it should describe it as something with needed list of data
15:29:54 <caitlin56> Maybe manila-network-context? or manila-secfurity-domain?
15:29:59 <bswartz> #topic better name for network-infos
15:30:32 <bswartz> anyone want to make some suggestions for a better term?
15:30:49 <bswartz> just remember that these objects are each directly mapped to neutron subnets
15:31:06 <vbellur> maybe network-context
15:31:09 <achirko> secfurity-domain sounds good
15:31:14 <vponomaryov> neutron is a plugin for this
15:31:26 <vponomaryov> potentially, it can be something else
15:31:46 <achirko> with --network argument to specify neutron parameters
15:32:24 <jcorbin> Can a share only have one of these or multiple of these network-infos?
15:32:25 <caitlin56> yponomaryov: what is the name of the handle within maniala that selects neutron typically?
15:32:42 <bswartz> jcorbin: every share has exactly 1 of these
15:33:18 <vponomaryov> caitlin56: with config
15:33:36 <caitlin56> And this thing defines a *set* of servers, correct? It's not just your LDAP/AD, it is the associated DNS, etc.
15:34:04 <vponomaryov> yes, "ip for dns" string present too
15:34:10 <caitlin56> yponomaryov: what is the configurable's name? That is the name we should use to refer to "neutron".
15:34:31 <jcorbin> Does this thing define 'connectivity', what the share talks to?
15:37:05 <yportnova> cailtlin56: "network_plugin" is the name of config option
15:37:57 <bswartz> jcorbin: yes
15:37:57 <bswartz> the network-info object includes a mapping to a subnet (VLAN) which teh backend can use to provision an IP address if it needs to create a vserver to conenct to that VLAN
15:37:57 <bswartz> network-context is sounding good to me
15:37:57 <bswartz> secfurity-domain is the other suggestion I've heard
15:38:02 <caitlin56> jcorbin: I believe this thing defines the set of clients that can *successfully* talk to these servers.
15:38:02 <caitlin56> I could have a client that does not know what AD/LDAP server to talk to. It can connect to my vserver, but it will not be able to mount a share.
15:38:42 <bswartz> what about "network-security-context"
15:38:42 <bswartz> or "manila-network-context"?
15:38:46 <caitlin56> network-context still sounds like something that belongs to neutron.
15:38:58 <caitlin56> Either of the last two are better.
15:39:17 <bswartz> any other suggestions?
15:39:27 <scottda> share-network-context?
15:39:31 <bswartz> I'd like to call a vote on this
15:39:45 <caitlin56> scottda: +1
15:39:47 <vponomaryov> network-environment-data
15:39:59 <bswartz> share-network-context sounds good
15:40:10 <achirko> network-context and security-domain looks equally  good to me
15:40:14 <jcorbin> I think having the project name in the term is not a good idea.
15:40:31 <jcorbin> share-network-context +1
15:40:38 <caitlin56> The 'share' makes it clear that we are talking about something more specific than a VLAN.
15:40:42 <vbellur> share-network-context +1
15:40:45 <xyang1> +1 share-network-context
15:41:01 <bswartz> share-network-context +1
15:41:20 <bswartz> any opposed to share-network-context?
15:41:30 <bill_az_> share-network-context +1
15:41:42 <vponomaryov> and we will have command like "manila share-network-context-create ..." ? Right?
15:42:08 <achirko> share-network-context-security-service-add (command which we will support) looks terifying
15:42:22 <yportnova> Maybe make it shorter like "share-network"?
15:42:41 <achirko> maybe network-context?
15:42:42 <bswartz> hmm
15:42:57 <bswartz> achirko: I agree with caitlin56 that network-context sounds like it should belong to neutron
15:43:01 <achirko> or security-domain? :)
15:43:05 <bill_az_> share-context  - it is about more than just network
15:43:17 <scottda> "share" makes it explicit that we are referring to share management
15:43:32 <xyang1> share-netcontext?
15:43:42 <caitlin56> It's not like any human will be typing these commands. Everything is going to be scripts.
15:43:43 <bswartz> I prefer something with the name "share" or "manila" in the name
15:43:43 <bswartz> I agree that a long name such as share-network-context is a bit painful to read/type
15:44:23 <caitlin56> If you are typing it a lot you will be putting it in a script anyway.
15:44:35 <bswartz> caitlin56: not really -- us poor developers have to type this stuff, and the docs will have to include the full names
15:44:42 <vbellur> share-nw-context ?
15:45:56 <achirko> I don't think we should prepend 'share' - at the end everything in manila is about shares
15:46:09 <caitlin56> share-net-context?
15:46:09 <caitlin56> or share-net-ctx?
15:46:39 <vponomaryov> net-ctx and we are deal =)
15:46:53 <bswartz> share-netcontext seems to be the simplest shortening
15:46:53 <bswartz> or share-network
15:46:53 <bswartz> I don't like "nw" or "ctx" they're too short
15:47:26 <bswartz> how do people feel about share-network-context vs share-network vs share-net-context
15:47:41 <caitlin56> achirko: I disagree. When you are writing code this is obvious, but an admin can easily be confused about whether they are being asked to configure manila's use of a neutron object or a manila object.
15:47:45 <achirko> I like share-network
15:48:01 <jcorbin> share-network +1
15:48:03 <bswartz> share-network +1
15:48:07 <vbellur> share-network +1
15:48:09 <scottda> share-network +1
15:48:30 <yportnova> share-network +1
15:48:38 <bswartz> okay that's a bit less terrifying, and still pretty clear what it refers to
15:48:40 <vponomaryov> share-network +1
15:48:44 <caitlin56> context is almost like "handle", so leaving it off is not terribly confusing.
15:49:15 <bswartz> #agreed network-info will be renamed to share-network
15:49:32 <bswartz> #topic open-discussion
15:50:35 <bswartz> okay so it's my fault that we still don't have clear diagrams/documents explaining what manila is/how it works
15:50:35 <bswartz> I relaxed too much on vacation :-(
15:50:35 <bswartz> I'm going to work on that today
15:50:55 <caitlin56> Do we want to start discussing object relationships?
15:51:21 <bswartz> caitlin56: are you available later today?
15:51:41 <jcorbin> bwartz: If you need any help let me know.
15:51:52 <bswartz> I guess I forgot to mention that in case it's no clear from vponomaryov's updates, we're really close to having a fully working implementation of manila with multitenancy
15:51:53 <caitlin56> Yes, I'm still at home, so I have to actually finish walking the dog and then go into the office first thought (it not yet 8:00 AM here).
15:52:16 <bswartz> caitlin56: I will ping you after the meeting ends
15:52:23 <xyang1> what about NetApp's multitenancy driver?
15:52:46 <vponomaryov> xyang1: it is inprogress
15:52:56 <xyang1> ok, thanks
15:53:12 <bswartz> xyang1: it's in gerrit, as a WIP
15:53:14 <vponomaryov> we should make it work with kerberos and ldap and network-API
15:53:41 <bswartz> vponomaryov: is that change viewable by the public?
15:53:55 <xyang1> bswartz: ok, I'll take a look
15:54:03 <vponomaryov> driver is in gerrit
15:54:04 <bswartz> in any case I can add xyang1
15:56:20 <bswartz> okay if nobody else has anything we can wrap up
15:56:20 <bswartz> thanks everyone
15:56:20 <bswartz> #endmeeting