15:01:23 <bswartz> #startmeeting manila
15:01:24 <openstack> Meeting started Thu Feb 27 15:01:23 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:27 <openstack> The meeting name has been set to 'manila'
15:01:37 <bswartz> good morning/evening folks
15:01:46 <vponomaryov> Hello
15:01:47 <xyang1> hi
15:01:55 <scottda> Hi
15:02:10 <bswartz> I don't have an agenda today
15:02:18 <bswartz> last 3 days I took a vacation to cinder land
15:02:55 <bswartz> There were some last minute I-3 things that needed some attention
15:03:03 <yportnova> hi
15:03:18 <bswartz> but manila is just as important
15:03:35 <bswartz> actually I do have one thing
15:03:49 <bswartz> I understand there are some folk in Australia who are very interested in manila
15:04:21 <bswartz> but they can't attend this meeting because it's sometime after midnight right now
15:05:05 <bswartz> I want to accomodate some of the oceania timezones better
15:05:28 <bswartz> the 2 options we have are to do an alternating meeting, or to keep these meetings and add a suplemental meeting for the oceania folks
15:06:10 <vponomaryov> bswartz: for first step they can use manila chat
15:06:20 <vponomaryov> without schedule
15:07:02 <scottda> I notice that openstack-manila is very quiet. Or is it just me?
15:07:18 <bswartz> either way, I would probably propose 0100 UTC or 0200 UTC for the alternate meeting
15:08:43 <bswartz> scottda: yeah that's been the trend
15:09:01 <bswartz> scottda: most of the conversations are during these weekly meetings or in offline meetings
15:09:23 <bswartz> we already have someone serious timezone issues
15:09:27 <scottda> OK, probably also a result of such a small group of devs and users
15:09:40 <bswartz> yeah the group is small and very spread out around the world
15:09:48 <bswartz> if some of the australians join then that will get worse
15:10:10 <vponomaryov> chat is quiet - yes, but who restricts to have a talk?
15:10:16 <bswartz> but I'm nearly always online during USA hours and you can ping me if you want to talk
15:10:51 <bswartz> anyways I just wanted to mention that briefly
15:10:58 <bswartz> we don't make any changes to the meeting schedule yet
15:11:30 <bswartz> I'll start up some conversations and maybe we can move to 1.5 meetings per week
15:11:55 <bswartz> with the 0.5 meetings per week being at 0200 UTC in addition to the current regular meeting
15:11:57 <bswartz> enough on that
15:12:04 <bswartz> #topic dev status
15:12:21 <vponomaryov> Dev status:
15:12:32 <vponomaryov> 1) NetApp Cmode driver: https://review.openstack.org/#/c/59100/
15:12:32 <vponomaryov> Waiting for reviews, after changes. Not critical nits are expected to be fixed after main merge of driver.
15:13:05 <vponomaryov> 2) Horizon's manila extension: https://github.com/NetApp/horizon/tree/manila
15:13:17 <bswartz> oh Jenkins is passing again
15:13:27 <bswartz> thanks yportnova -- I'll review that change again
15:13:38 <vponomaryov> 3) Devstack with generic driver: https://review.openstack.org/#/c/74647/
15:13:38 <vponomaryov> related bug: https://bugs.launchpad.net/manila/+bug/1285612
15:14:03 <vponomaryov> 4) Generic driver's modularity: https://review.openstack.org/#/c/74154/
15:14:03 <vponomaryov> Waiting for reviews, after changes. Not critical nits are expected to be fixed after main merge
15:14:27 <vponomaryov> 5) Volume types: https://review.openstack.org/#/c/74772/ (client)
15:14:43 <vponomaryov> 6) Activation/deactivation api: https://blueprints.launchpad.net/manila/+spec/share-network-activation-api
15:14:43 <vponomaryov> (server) https://review.openstack.org/#/c/71936/
15:14:43 <vponomaryov> (client) https://review.openstack.org/#/c/71497/
15:14:43 <vponomaryov> Not tested due to absence of its using in drivers.
15:15:01 <vponomaryov> TODO:
15:15:03 <bswartz> so this reminds me of somethiong
15:15:28 <bswartz> I've decided to create some branches on github under the NetApp account for horizon and tempest
15:15:45 <bswartz> because we have changes to both of those projects that can't go upstream yet
15:16:13 <bswartz> so the NetApp version of those branches will be the "official" ones until we're incubated
15:16:17 <bswartz> unless someone has a better idea
15:16:31 <bswartz> if anyone wants to contribue to those branches I can grant access
15:16:56 <bswartz> it's just github though so there's no review/gate process and therefore we need to be careful
15:17:26 <vponomaryov> branch per dev
15:18:06 <bswartz> we need some reviews on the above changes please
15:18:15 <bswartz> in addition to my own
15:18:52 <bswartz> the rest I don't know if they need any discussion
15:18:57 <bswartz> vponomaryov: were you going to mention some todo items?
15:19:02 <vponomaryov> So, back to status, TODO:
15:19:10 <vponomaryov> 1) Make drivers (Generic, Cmode) use activation/deactivation API
15:19:17 <vponomaryov> 2) Update Horizon extension for Manila due to API changes, bugfixing
15:19:26 <vponomaryov> 3) Implement volume types server side
15:19:34 <vponomaryov> OPEN ITEMS:
15:19:42 <vponomaryov> 1) metadata for security-services.
15:20:03 <vponomaryov> 2) cirros lightweight image for generic driver :
15:20:03 <vponomaryov> - has nonworking nfs - https://github.com/csabahenk/cirros/issues?direction=asc
15:20:19 <vponomaryov> that's all
15:20:41 <bswartz> csaba: you here?
15:21:31 <bswartz> how much of a blocker is the nonworking NFS is the image? can't we just use other (heavier) images until that's fixed?
15:21:48 <vponomaryov> yes, we can
15:22:12 <vponomaryov> it is blocker for devstack plugin for enabling generic driver
15:22:16 <vponomaryov> one of two blockers
15:22:41 <vponomaryov> second, as I have mentioned in dev status is a bug: https://bugs.launchpad.net/manila/+bug/1285612
15:22:59 <bswartz> uh oh looks like Freenode is still unstable -- I see a netsplit happening
15:23:32 <bswartz> well in case csaba is reading the meeting log, csaba: reach out for help if you need it
15:23:45 <csaba> bswartz: yep
15:23:56 <csaba> just came soory
15:24:34 <csaba> so yeah I know the image is non functional yet
15:24:43 <bswartz> vponomaryov: is this really a manila bug or a devstack bug?
15:25:05 <vponomaryov> it is conceptual bug for dependency, that generic driver has
15:25:14 <vponomaryov> it is manila bug
15:25:22 <bswartz> csaba: welcome!
15:26:06 <bswartz> vponomaryov: do you have a fix in mind?
15:26:34 <vponomaryov> We have thoughts, need test it
15:26:39 <bswartz> I read the bug and I'm not clear on the problem
15:26:43 <vponomaryov> it will take some time
15:26:47 <yportnova> bswartz: need to clarify if it is generic driver's bug or bug related to service starting
15:26:55 <bswartz> okay
15:27:13 <csaba> vponomaryov: can you suggest a hotfix?
15:27:32 <csaba> just in order to be able to do testing with devstack
15:27:46 <vponomaryov> there are workaround
15:27:56 <vponomaryov> just run LVM driver first
15:28:01 <vponomaryov> or cmode
15:28:03 <bswartz> can we just hack devstack into working shape manually?
15:28:13 <vponomaryov> than enable generic driver and restart m-shr
15:28:43 <csaba> do you need to create an lvm share or is it enough to just start m-shr with lvm ?
15:28:49 <bswartz> ok
15:28:53 <vponomaryov> just start
15:28:59 <csaba> cool
15:29:17 <bswartz> vponomaryov: you may want to mention that workaround in the bug notes
15:29:32 <bswartz> so people who read it aren't stuck waiting for the bug to be fixed
15:29:35 <vponomaryov> currently, devstack plugin works with lvm
15:29:48 <vponomaryov> this bug for commit: https://review.openstack.org/#/c/74647/
15:29:57 <vponomaryov> that changes devstack plugin
15:30:26 <bswartz> ok
15:30:33 <vponomaryov> so, those who don't use this commit, won't face it
15:30:51 <csaba> and what does lvm driver do to have such an effect?
15:31:09 <vponomaryov> it has not such dependency, that has generic driver
15:31:23 <vponomaryov> dependency oh host record
15:32:04 <yportnova> csaba: the problem is that generic driver reads on start db record from services table and at that time it is missing. So it fails
15:32:19 <csaba> ah so host record in db
15:32:29 <csaba> I see thx
15:33:15 <xyang1> vponomaryov: to enable generic driver, just change the driver entry in manila.conf and restart m-shr (after run lvm driver)?
15:33:42 <vponomaryov> xyang1: no, it has much more dependencies
15:34:03 <vponomaryov> xyang1: see changes here https://review.openstack.org/#/c/74647/
15:34:18 <xyang1> vponomaryov: thanks.  will take a look
15:34:31 <bswartz> okay
15:34:35 <bswartz> #topic open discussion
15:34:44 <bswartz> anyone have anything else?
15:34:51 <vponomaryov> First point from open items
15:34:53 <vponomaryov> 1) metadata for security-services.
15:35:15 <bswartz> okay
15:35:29 <vponomaryov> no problem if we add it?
15:36:02 <bswartz> sorry I'm not sure what you mean
15:36:06 <bswartz> is this something new?
15:36:17 <vponomaryov> I mean extending manila's API
15:36:22 <bswartz> the share-network has all kind of security key/values
15:36:27 <vponomaryov> to allow set metadata for security services
15:36:33 <bswartz> what would such metadata be used for?
15:36:42 <vponomaryov> For example, for kerberos in Cmode driver now we have hardcoded username for spn record - "nfs".
15:36:59 <vponomaryov> It can be different for each vserver
15:37:11 <vponomaryov> theoreticaly
15:37:23 <bswartz> why not make that an additional key/value in the share-network?
15:37:35 <bswartz> with a sensible default value
15:38:03 <vponomaryov> it is part of security service, not share-network
15:38:42 <bswartz> what's a security service?
15:39:03 <bswartz> I feel like I'm missing something here
15:39:08 <vponomaryov> security-service, which is part of manla's API
15:39:21 <vponomaryov> we set there ldap, ad and kerberos data
15:39:50 <vponomaryov> then attach this entities to share-network, that is used to make shares
15:40:04 <bswartz> okay I feel dumb
15:40:17 <bswartz> yes that's right
15:40:37 <bswartz> I forgot about the exact way the share-network API worked
15:41:22 <bswartz> so the proposal is to allow attaching metadata to those security-services?
15:41:30 <vponomaryov> yes, exactly
15:41:45 <bswartz> and who would have access to do that?
15:41:48 <bswartz> tenants or admins?
15:42:22 <vponomaryov> as for creation of sec services - admins
15:43:01 <vponomaryov> if by tenant you mean common users
15:43:06 <bswartz> I guess my concern is that the term "metadata" typically refers to data that the API server will ignore
15:43:32 <vponomaryov> yes, it will send as is
15:43:38 <vponomaryov> key-value
15:43:40 <bswartz> if the APIs are looking at the metadata and changing their behavior based on those values then they're not really metadata -- they're API inputs
15:44:03 <vponomaryov> drivers can use it
15:44:11 <bswartz> I think of metadata as stuff the server stores and hands back to you but never really looks at
15:45:42 <vponomaryov> it depends on realisation
15:45:51 <vponomaryov> mostly yes
15:46:07 <bswartz> I think the idea makes sense but it can't be called metadata
15:46:18 <bswartz> it should be called somethign else
15:46:20 <bswartz> like attributes
15:47:01 <vponomaryov> it is expected to be the same as metadta for shares, volumes, etc
15:47:38 <bswartz> except those values are truly metadata aren't they?
15:48:31 <vponomaryov> as rule metadata has one restriction - length
15:48:42 <vponomaryov> and custom keys with values
15:49:13 <bswartz> vponomaryov: we should probably follow up on this offline because I want to think through an example in depth
15:49:27 <vponomaryov> Ok, agree, let it left to next meetings
15:49:35 <bswartz> thx
15:49:47 <bswartz> did anyone else have a topic?
15:50:03 <bswartz> otherwise I'll give you all 10 minutes back and I'll get started on code reviews
15:50:47 <bswartz> okay
15:50:53 <bswartz> thanks all
15:50:54 <bswartz> #endmeeting