15:01:30 <bswartz> #startmeeting manila
15:01:31 <openstack> Meeting started Thu Jul 24 15:01:30 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:35 <openstack> The meeting name has been set to 'manila'
15:01:36 <cknight> Hi
15:01:39 <bswartz> hello all
15:01:43 <vponomaryov> hello
15:01:46 <xyang1> hi
15:01:50 <rraja> hi
15:01:52 <deepakcs> hi all
15:01:56 <scottda> hi
15:02:02 <bswartz> sorry for my absence last week -- it was unavoidable
15:02:04 <dustins> o/
15:02:10 <ameade> o/
15:02:35 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:07 <bswartz> hmm I have one thing to stick in before we start the agenda
15:03:13 <bswartz> #topic incubation
15:03:33 <bswartz> I plan to send the request for incubation to the OpenStack TC tomorrow
15:03:40 <deepakcs> bswartz, nice
15:03:52 <bswartz> #link https://wiki.openstack.org/wiki/Manila/Incubation_Application
15:04:24 <bswartz> this is your last chance to add an information about yourselves to the 'Project developers qualifications' section
15:05:04 <bswartz> it will help if we fill out that section I think
15:05:17 <vponomaryov> bswartz: everyone can participate in incubation meeting with TC?
15:05:33 <bswartz> so the way that it works is that I send a mail to the openstack-dev ML
15:05:46 <bswartz> and I CC the technical committee ML
15:05:50 <bswartz> and they give us a date
15:05:52 <xyang1> bswartz: it still says my core membership pending team vote?:)
15:06:00 <bswartz> the TC meets on Tuesday afternoons at 3PM (?)
15:06:09 <bswartz> xyang1: DOH
15:06:19 <bswartz> we'll get it fixed
15:06:27 <bswartz> I still have to do my updates
15:06:43 <bswartz> the TC meetings are open to everyone
15:06:48 <xyang1> bswartz: thanks:)  I'll update my profile as well before tomorrow
15:07:29 <deepakcs> bswartz, for other TZ users, do we get to see what TC discussed ?
15:07:37 <bswartz> #link https://wiki.openstack.org/wiki/Meetings#Technical_Committee_meeting
15:07:45 <bswartz> 2000 UTC is the meeting time
15:08:06 <bswartz> deepakcs: it's like any other meeting -- it's run by the openstack bot and logged, etfc
15:08:08 <bswartz> etc*
15:08:10 <scottda> meeting is 3PM EDT? so is that 19:00 UTC?
15:08:18 <deepakcs> bswartz, cool
15:08:18 <bswartz> 2000 UTC
15:08:22 <scottda> thx
15:08:44 <bswartz> typically the date for consideration will be a few weeks away
15:08:51 <bswartz> we'll see though and I'll let you all know
15:08:57 <bswartz> enough on that
15:09:12 <bswartz> #topic dev status
15:09:20 <vponomaryov> Dev status:
15:09:32 <vponomaryov> 1) Test framework for Manila was refactored
15:09:32 <vponomaryov> see commit: #link https://github.com/stackforge/manila/commit/16a04df3d0da5d6f51b7572c9fe2794c0bd718c1
15:09:47 <vponomaryov> 2) '--share-server' filter opt for share list API
15:09:47 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/add-admin-api-list-shares-for-share-server
15:09:47 <vponomaryov> gerrit, server side: #link https://review.openstack.org/107729
15:09:47 <vponomaryov> gerrit, client side: #link https://review.openstack.org/108312
15:09:47 <vponomaryov> status: finished, ready for review
15:10:05 <vponomaryov> 3) oslo.db
15:10:05 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/oslo.db
15:10:06 <vponomaryov> gerrit: #link https://review.openstack.org/106766
15:10:06 <vponomaryov> status: finished, ready for review
15:10:19 <vponomaryov> 4) Usage of common code
15:10:23 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/use-common-code
15:10:28 <vponomaryov> gerrit, manila: #link https://review.openstack.org/#/q/status:open+project:stackforge/manila+branch:master+topic:bp/use-common-code,n,z
15:10:32 <vponomaryov> gerrit, manilaclient: #link https://review.openstack.org/#/q/status:open+project:stackforge/python-manilaclient+branch:master+topic:bp/use-common-code,n,z
15:10:37 <vponomaryov> status: commits are ready for review, bp is in progress
15:10:52 <vponomaryov> that's all for dev status
15:11:22 <bswartz> okay
15:11:26 <bswartz> looks good
15:11:45 <bswartz> vponomaryov: do we have vlad here by any chance?
15:11:48 <bswartz> or is that next week?
15:11:57 <vponomaryov> bswartz: he is vacation
15:12:11 <bswartz> okay do you know his IRC handle?
15:12:15 <vponomaryov> bswartz: he is on vacation this and next week too
15:12:22 <bswartz> oh ok
15:12:43 <vponomaryov> bswartz: maybe vvechkanov, but I am not sure
15:12:52 <bswartz> look forward to him joining
15:13:08 <vponomaryov> bswartz: you mean contributor list?
15:13:36 <bswartz> vponomaryov: no I'm not concerned about that
15:13:53 <bswartz> just looking forward to seeing him in these meetings
15:13:56 <bswartz> #link Follow up to launchpad ownership question for manila client
15:14:00 <bswartz> errr
15:14:07 <bswartz> #topic Follow up to launchpad ownership question for manila client
15:14:22 <bswartz> is this an old item from last week?
15:14:39 <bswartz> we have full control of python-manilaclient on LP
15:14:47 <bswartz> and I think we have bugs and BPs setup
15:14:53 <bswartz> any remaining issues here?
15:15:08 <vponomaryov> bswartz: its ok
15:15:19 <bswartz> okay
15:15:22 <bswartz> #topic Support for SID-based access control in manila client
15:15:38 <bswartz> cknight / ameade: who wants to cover this?
15:15:52 <vponomaryov> in "manilaclient"?
15:15:52 <cknight> bswartz: I can
15:16:19 <cknight> We're working on access groups, and we need to know if SID support is to be maintained.
15:16:33 <cknight> It doesn't appear to be complete.
15:16:41 <bswartz> I don't think SIDs are a reasonable way to manage access
15:16:49 <vponomaryov> cknight: cmode driver uses it for cifs
15:16:52 <bswartz> I think IPs, networks, and Users make sense
15:17:01 <vponomaryov> cknight: sid rules are the only for cifs in Cmode
15:17:11 <bswartz> vponomaryov: we should be using Users though
15:17:27 <cknight> SIDs map to users or groups in the Windows world, and ONTAP uses them.
15:17:30 <bswartz> SIDs are incredibly user-unfriendly
15:17:33 <vponomaryov> bswartz: sid rules it is exactly about users and groups
15:17:59 <bswartz> so SIDs are used underneath, for sure, but users should be able to specify User NAMEs or Group NAMEs
15:18:02 <deepakcs> just curious, what does SID expand to ?
15:18:55 <cknight> deepakcs:  Security identifier  #link http://en.wikipedia.org/wiki/Security_Identifier
15:19:01 <bswartz> and reason we can't do that?
15:19:14 <deepakcs> cknight, thx
15:20:23 <vponomaryov> bswartz: your proposal to rename sid into users?
15:20:24 <bswartz> err any*
15:20:43 <vponomaryov> bswartz: 'sid' as key for access rule?
15:20:44 <bswartz> vponomaryov: yes the tenant-facing API should be in terms of users and groups, not SIDs
15:21:06 <bswartz> one problem that cknight pointed out is that out database fields aren't even wide enough for SIDs :-(
15:21:59 <bswartz> that's my opinion at least
15:22:05 <bswartz> I'm looking for disagreement
15:22:29 <bswartz> I can't see any benefit to using SIDs over names
15:23:17 <cknight> Do we know if any users are using the SID feature?
15:23:36 <bswartz> I can't imagine
15:23:42 <bswartz> I'm not aware of any
15:23:56 <bswartz> let's get it fixed soon
15:24:09 <vponomaryov> bswartz: only client side?
15:24:14 <vponomaryov> bswartz: or server too?
15:24:31 <bswartz> the API is what needs fixing
15:24:39 <bswartz> I imagine that will impact both the client and server
15:24:46 <vponomaryov> bswartz: topic is about manilaclient
15:24:57 <cknight> bswartz: we can yank it as part of the access group work, or after the group stuff is merged
15:25:14 <bswartz> cknight: what is your feeling? does it impact the server
15:25:46 <cknight> It ripples through, but mostly in the APIs.
15:25:54 <bswartz> that's what I assumed
15:25:58 <bswartz> glad I'm not crazy
15:26:11 * bswartz wonders if he is crazy anyways
15:26:49 <bswartz> ok I think that issue is closed
15:26:51 <cknight> bswartz: so can this be part of the groups commit, or done afterwards?
15:27:07 <bswartz> cknight: we can talk about how to manage the work
15:27:12 <bswartz> I think we agree on the goal
15:27:19 <bswartz> #topic cert-based-access-type
15:27:30 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/cert-based-access-type
15:27:42 <bswartz> deepakcs, you're up
15:27:54 <deepakcs> thanks bswartz , I have couple of things...
15:28:30 <bswartz> first of all, it looks like this is a glusterfs specific thing, right?
15:28:31 <deepakcs> ameade, can you provide more info on where exactly you see the overlap between cert bp and access groups bp ?
15:29:05 <deepakcs> bswartz, currently yes, but implmn won't be tied to glusterfs
15:29:51 <deepakcs> bswartz, I mean, its a new access type that can be implemented by any backend that supports it.
15:29:53 <ameade> deepakcs: it was just a thought around how access groups will need to support cert access rules, access groups will affect how rules are applied on the backend
15:30:03 <bswartz> deepakcs: what does a cert actually look like?
15:30:19 <deepakcs> ameade, right, so you mean instead of IP based group, it could potentially be a cert based access group ?
15:30:20 <bswartz> do you have a proposed encoding format?
15:30:34 <deepakcs> bswartz, its X509 standard SSL certificate. (.pem files)
15:30:45 <bswartz> my big concern here is that DER-encoded X.509 is MASSIVE compared to usernames and IP addresses
15:30:54 <ameade> deepakcs: yeah
15:30:58 <cknight> deepakcs: where are the certs stored, and how are they specified to manila?  The access mapping tables won't currently hold anything that large.
15:31:32 <deepakcs> bswartz, massive meaning ? glusterfs uses openssl to create and use certs. I think they are DER encoded, need to cross check
15:32:02 <bswartz> I mean they are typcially several hundred bytes -- sometimes multiple KBs
15:32:04 <deepakcs> bswartz, we don't put the DER encoded string in the access_type.. we use the CN (Common Name) to determine the access type
15:32:11 <bswartz> not exactly a great thing to shove into a database
15:32:23 <deepakcs> bswartz, CN is inside the certificate, which is the person to which the cert is issued to
15:32:41 <cknight> bswartz: it could be a blob, but would have to live in a separate table
15:32:46 <ameade> bswartz: do we need a key-data store?
15:32:56 <bswartz> well wait a minute
15:33:10 <deepakcs> cknight, the way glusterfs uses it.. its stored on the client and server sides (under /etc/ssl)
15:33:10 <bswartz> is the proposal here to only tell manila about the CN of the certificate
15:33:17 <bswartz> and to keep the actual certificate outside manila?
15:33:38 <bswartz> because that would actually be really easy
15:33:45 <bswartz> (if it works)
15:33:56 <deepakcs> bswartz, certificate creation and trust setup between instance and server is done as part of backend work. thats my thinking.
15:34:19 <bswartz> deepakcs: is it out of band or inside the manila backend
15:34:20 <bswartz> ?
15:34:31 <bswartz> if it's completely out of band then that's great
15:34:40 <ameade> what's the value then?
15:34:49 <deepakcs> bswartz, as part of access_allow and access_deny, my thoguht was to add trust (by way of setting the certs) and remove trust (by way of removing certs)
15:34:51 <bswartz> if manila is involved in any way with creation of certificates then it has to be able to transmit them
15:34:58 <scottda> What will push the client's cet into the instance? Manila or backend or ??
15:35:04 <scottda> cet -> cert
15:35:10 <bswartz> and if we need to transmit them then we need to care about encoding and storage of them
15:35:17 <ameade> ah ok
15:35:57 <bswartz> if the creation and transmission of the certs is outside of manila, then all manaila would have to do is manage the list of allowed certs
15:36:06 <deepakcs> I am open to suggestions.. put my current thinkign was NOT to have manila manage certificates , since i believe that is backedn specific
15:36:09 <bswartz> that doesn't sound scary to me
15:36:32 <deepakcs> s/put/but
15:36:38 <bswartz> deepakcs: how far along is the implementation of this? can we see a WIP?
15:37:16 <deepakcs> bswartz, I just started... nothing to show yet. I am figuring the work flows for this, and had a question in that regards too.
15:37:24 <bswartz> deepakcs: the part where I get nervous is when you say "backend" -- do you mean manila backend or the storage controller itself?
15:37:48 <deepakcs> bswartz, sorry if my nomeclature was not clear. I mean the manila driver will setup the cert and enable the trust
15:38:05 <deepakcs> bswartz, by working with the client (instance) and backend (server)
15:38:30 <deepakcs> by server I mean the glusterfs server here
15:38:44 <bswartz> deepakcs: I know you don't have this right now, but maybe you can come up with a step by step sequence of operations that a tenant would do
15:38:47 <vponomaryov> deepakcs: but who produces certs and transfers it?
15:39:03 <deepakcs> vponomaryov, the manila driver for glusterfs would do it
15:39:07 <bswartz> from beginning to end, including the inputs and outputs and what goes where
15:39:11 <deepakcs> bswartz, I added soem steps in the bp, did u see it ?
15:39:33 <bswartz> it's still very unclear if manila ever touches the certificate itself
15:39:40 <bswartz> or if manila just handles CNs
15:40:08 <deepakcs> bswartz, Per my current thinking.. manila only handles the CNs. In fact CNs are derived from instance ID or tenant ID
15:40:15 <bswartz> because someone needs to create there certs and sign them
15:40:18 <nileshb> and the certs are stored in manila db?
15:40:24 <bswartz> if that's an "out of band" activity then I have no issue with this
15:40:26 <deepakcs> bswartz, Manila only says "I want to use cert based access for this instance UUID for this share"
15:40:41 <bswartz> deepakcs: I think you're on the right track then
15:40:49 <scottda> deepaks: How will you modify the instance? to put the cert in the proper place?
15:40:54 <bswartz> why don't you proceed with the work and show us when you have something?
15:40:56 <deepakcs> bswartz, i don't understand when u say "out of band"..what does that mean ?
15:41:38 <deepakcs> scottda, Like how today we do ssh in service VM and do exportfs ... similarly my thought was to get into instances using ssh. I hope that is possible ?
15:41:51 <vponomaryov> deepakcs: manila is requester not handler for cert activity
15:41:56 <bswartz> I mean that the client and server setup their keys and certs in a way that doesn't involve manila, and manila is only involved in the last step -- where access to the share is granted based on the preexisting cert
15:41:56 <cknight> deepakcs: is any of this reusable by other (future) drivers?  That is, should the driver manager be doing anything you plan to put in GlusterFS driver?
15:42:00 <deepakcs> vponomaryov, you can say so
15:42:14 <deepakcs> bswartz, yes, i agree to that
15:42:35 <bswartz> okay that sounds perfect
15:42:44 <scottda> deepakcs: I am not so sure on this. Manila owns the service VM, so Manila can ssh to it to do exportfs. But Manila does not own the tenant VM instance.
15:42:53 <deepakcs> cknight, so you mean we can put some APIs in driver manager to handle the client and server certs and trust.. which can be implemented diff for other future drivres ?
15:42:55 <deepakcs> *drivers ?
15:43:05 <ameade> i'm still not clear on everything the tenant would have to do
15:43:15 <cknight> deepakcs: yes, that's what I'm asking
15:43:25 <deepakcs> cknight, that can be done too
15:43:25 <ameade> even outside of manila
15:43:33 <deepakcs> scottda, ok.. I also need to think on that.
15:43:41 <bswartz> ameade: I think the client and server would have a prexisting relationship (through a shared CA)
15:43:55 <deepakcs> bswartz, that will be setup as part of access_allow
15:44:19 <bswartz> that's no different than a client and a server having a prexisting relationship through a shared AD controller, for example
15:44:22 <deepakcs> bswartz, for it to be pre-existing the instance virtual disk image will have the certs before itself, that may not be possible, always rite ?
15:44:37 <ameade> bswartz: how do they get that prexisting relationship? excuse my ignorance on the subject
15:44:48 <bswartz> assuming the client and the server both have private keys and certs signed by the same CA, then manila just needs to take the name from the client cert and give that to the server and say "allow this"
15:44:57 <bswartz> all the tenant has to do is tell manila the name from the cert
15:45:35 <deepakcs> bswartz, so are u suggesting that the instance (client) will use an disk image that will have signed certs pre-loaded ?
15:46:02 <bswartz> deepakcs: that would be a problem left to the user
15:46:08 <bswartz> it's no different than CIFS or Kerberos
15:46:26 <deepakcs> bswartz, Hmm i don't fully understand, but ok!
15:46:28 <bswartz> the tenant VM has to have a relationship with some authority and how they set that up is outside manila
15:46:56 <deepakcs> bswartz, the certs have CN which I plan to use as the instance or tenant ID (based on what granularity we need to provide the access)
15:47:05 <bswartz> A certificate authority is just another type of authority
15:47:10 <deepakcs> bswartz, these UUIDs won't be known beforehand, so pre-loaded certs won't be helpful
15:47:33 <bswartz> deepakcs: clearly there would need to be a workflow involving new VMs and the CA
15:47:40 <bswartz> but manila wouldn't need to be part of that
15:47:46 <bswartz> it would be a precondition
15:47:49 <deepakcs> bswartz, I hope its clear that the cert bp is applicable only to the native glusterfs protocol (not for nfs/cifs)
15:47:58 <bswartz> yes of course
15:48:18 <ameade> imo, we need to be concerned with the entire UX so preconditions and postcondtions to the actual manila process still matter
15:48:19 <deepakcs> bswartz, ok
15:48:43 <ameade> even if the manila process is simple, if it's a pain to get to that point nobody will do it
15:48:45 <bswartz> some of you may not be aware, but a AD controller and a KRB domain controller actually acts like an automated certificate authority
15:49:00 <cknight> deepakcs: but please assume that a future driver may want the same feature, so design with reusability in mind
15:49:02 <bswartz> you're just not exposed to the gory details of that when you use CIFS or NFS
15:49:22 <deepakcs> cknight, sure, and i look to you and others to correct me too :)
15:49:30 <bswartz> in the case of GlusterFS, it looks like you will be exposed to the gory details, but doesn't sound too bad to me
15:50:00 <deepakcs> bswartz, For now, GlusterFS usage of certs is very raw... but in future that can change.. currently the certs needs to be setup manually
15:50:13 <deepakcs> bswartz, which will be done by the gluster driver for manila for native protovcol
15:50:50 <cknight> deepakcs: it may be useful to you to do a telecon with us to determine if/how your changes work with the access group work.  Probably no issue there, but we should be aligned.
15:50:51 <deepakcs> bswartz, Does the 'high level steps' in the BP help you are we need more granular steps ?
15:50:55 <bswartz> deepakcs: I think we can make this work -- just let me know when you have something ready to show
15:51:18 <bswartz> deepakcs: no don't worry about it -- I was just trying to be sure that the actual cert handling was outside of manila not inside
15:51:34 <deepakcs> bswartz, sure, i will start on this. But as i said, i have few questions wrt implemetation.. esp creating siubnet between instance and glusterfs server. maybe i will shoot a mail to the -dev list
15:51:43 <deepakcs> bswartz, ok thanks
15:52:03 <deepakcs> cknight, sure, we can definitely havea  call. Maybe once i have something to show/work, its better to have a call ?
15:52:19 <bswartz> deepakcs: the networking aspect of this is a different matter
15:52:33 <deepakcs> bswartz, yeah and I am a bit naive there.
15:52:39 <cknight> deepakcs: your call, just trying to save some work
15:52:48 <deepakcs> cknight, sure, will keep you posted
15:52:50 <bswartz> I'm still assuming that glusterFS operates in a fundamentally flat networking model
15:53:20 <bswartz> if glusterFS has new and interesting network capabilities, that's a different topic to discuss
15:53:22 <deepakcs> bswartz, flat meaning ? It only has IP based access controls today
15:53:29 <bswartz> correct
15:53:50 <deepakcs> bswartz, new capabilities could be there in future.. for now its plain IP based access controls only
15:53:57 <bswartz> let's not confuse cert-based authentication with networking
15:54:04 <bswartz> networking is complicated enough by itself
15:54:12 <deepakcs> bswartz, Well, what i was trying to say ....
15:54:39 <deepakcs> bswartz, that the plan was to create a subnet between client and glusterfs server and then use cert based access for glusterfs mount
15:54:51 <deepakcs> bswartz, bcos its possible to have same same IP across different tenants
15:55:17 <bswartz> deepakcs: you can do either one without the other
15:55:33 <deepakcs> bswartz, using subnets would provide network level isolation, which is a good thing to have
15:55:39 <bswartz> we can have the networking discussion, just not right now
15:55:47 <deepakcs> bswartz, just cert baesd won't provide L2 level isolation
15:55:55 <deepakcs> bswartz, ok
15:55:58 <bswartz> the issues are orthagonal
15:56:18 <bswartz> authentication and routing have nothing to do with eachother, really
15:56:26 <bswartz> okay
15:56:29 <bswartz> #topic open discussion
15:56:36 <deepakcs> bswartz, need to catch u offline to discuss more
15:56:40 <bswartz> anything else in our last few minutes?
15:57:13 <bswartz> I saw a question in #manila
15:57:18 <bswartz> (11:48:55 AM) smcginnis: Hello. Curious if there is any driver development documentation for manila yet. Similar to what cinder has here: http://docs.openstack.org/developer/cinder/devref/drivers.html
15:58:37 <xyang1> I've only found API docs, but not driver dev docs for Manila
15:58:38 <bswartz> smcginnis: developer docs is one of the things we don't have
15:58:49 <bswartz> at least not good driver development docs
15:58:58 <bswartz> smcginnis: I would suggest using the generic driver as a model
15:59:09 <vponomaryov> provided one for Cinder hard to call a doc, it just mention interfaces
15:59:13 <bswartz> do no use the LVM driver as a model -- it's deprecated and will be going away
15:59:34 <vkozhukalov> hey, guys
15:59:48 <vkozhukalov> ready for fuel meeting?
15:59:52 <bswartz> and we're out of time, unfortunately
15:59:59 <xyang1> NetApp Cluster mode driver is actually a better example if driver support multitenancy
16:00:01 * bswartz waves to vkozhukalov
16:00:09 <mattymo> Hi gentlemen
16:00:14 <bswartz> and I agree with xyang1
16:00:20 <bswartz> look at the netapp cluster mode driver too
16:00:26 <bswartz> okay we're getting kicked out
16:00:30 <bswartz> thanks all!
16:00:34 <deepakcs> thanks all
16:00:36 <cknight> bye all
16:00:41 <mihgen> =) crowd is here
16:00:42 <xyang1> thanks
16:00:42 <dustins> Thanks!
16:00:43 <bswartz> #endmeeting