15:03:13 <cknight> #startmeeting manila
15:03:13 <openstack> Meeting started Thu Jul 17 15:03:13 2014 UTC and is due to finish in 60 minutes.  The chair is cknight. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:16 <openstack> The meeting name has been set to 'manila'
15:03:24 <cknight> Hi, manila team.
15:03:26 <ameade> o/
15:03:38 <xyang1> hi
15:03:40 <vponomaryov> Hello
15:03:49 <scottda> hi
15:03:49 <rraja> hi
15:03:50 <georgkunz> hi
15:03:51 <cknight> Our illustrious PTL, bswartz, has an unavoidable conflict today.  He sends his apologies.
15:04:17 <deepakcs_> cknight, blame his calendar ;-)
15:04:22 <tbarron> hi
15:04:27 <cknight> #topic Development Status
15:04:34 <cknight> vponomaryov, you're up
15:04:39 <vponomaryov> Dev status:
15:04:43 <vponomaryov> 1) '--share-server' filter opt for share list API
15:04:50 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/add-admin-api-list-shares-for-share-server
15:04:50 <vponomaryov> gerrit, server side: #link https://review.openstack.org/107729
15:04:50 <vponomaryov> status: work in progress
15:05:01 <vponomaryov> 2) refactor of test framework in manila:
15:05:06 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/testr-with-unittests
15:05:06 <vponomaryov> gerrit: #link https://review.openstack.org/107323
15:05:06 <vponomaryov> status: ready for review
15:05:14 <vponomaryov> 3) oslo.db
15:05:18 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/oslo.db
15:05:19 <vponomaryov> gerrit: #link https://review.openstack.org/106766
15:05:19 <vponomaryov> status: ready for review
15:05:28 <vponomaryov> 4) Usage of common code in manilaclient
15:05:33 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/use-common-code
15:05:38 <vponomaryov> gerrit:
15:05:44 <vponomaryov> #link https://review.openstack.org/106761
15:05:45 <vponomaryov> #link https://review.openstack.org/106869
15:05:45 <vponomaryov> #link https://review.openstack.org/106874
15:05:45 <vponomaryov> #link https://review.openstack.org/107017
15:05:45 <vponomaryov> #link https://review.openstack.org/107034
15:05:49 <vponomaryov> status: commits are ready for review, bp is in progress
15:06:06 <vponomaryov> that's all for status
15:06:58 <cknight> vponomaryov, thanks.  For #1, we didn't close last week on the CLI portion.  So —share-server is an optional argument to the existing list command?
15:07:12 <vponomaryov> cknight: yes
15:07:36 <cknight> vponomaryov: great, thanks.  makes more sense than adding a new command since we didn't add a new API.
15:07:49 <ameade> +1
15:08:01 <cknight> Anyone have any questions about any of the dev status?
15:09:02 <cknight> OK, sounds like we have much to review.  Thanks, vponomaryov.
15:09:03 <ameade> only thought i have around those things is that we dont seem to be keeping up with bp approvals and things
15:09:18 <deepakcs_> cknight, I am working on a new blueprint on provding new access_type = cert - just wanted to give heads up here.
15:09:32 <cknight> ameade: I'll ping Ben for the bp approvals.
15:09:34 <deepakcs_> We can probably discuss it once i put it up on LP
15:09:52 <ameade> deepakcs_: good to know!
15:09:59 <deepakcs_> ameade, :)
15:10:00 <cknight> deepakcs_:  OK, just add it to the agenda for next week if you're ready
15:10:10 <nileshb> An heads up from my side ... I am working on a new manila driver for IBM GPFS based systems
15:10:13 <deepakcs_> cknight, sure, where do i add it ? is there a wikipage ?
15:10:28 <deepakcs_> nileshb, is there a bp for that already ?
15:10:29 <nileshb> plan to submit a patch in a couple of weeks
15:10:35 <cknight> deepakcs_:  https://wiki.openstack.org/wiki/Manila/Meetings
15:10:36 <nileshb> yes
15:10:46 <deepakcs_> nileshb, cool, will take a look
15:10:50 <deepakcs_> cknight, thanks
15:11:09 <cknight> nileshb: is there a bp for the new driver?
15:11:12 <deepakcs_> cknight, I will send mail to openstack-dev with the bp link, hoping to get early feedback on the cert based access type
15:11:36 <nileshb> https://blueprints.launchpad.net/manila/+spec/gpfs-driver
15:11:46 <cknight> nileshb: thanks
15:11:58 <cknight> #topic Changes to generic & NetApp drivers for access groups
15:12:00 <nileshb> sure ... just had a discussion with Ben on this
15:12:06 <cknight> ameade:  your turn
15:12:49 <ameade> so really I just need to ask vponomaryov and Yulia a few questions about how the export rules for those drivers currently work
15:13:11 <ameade> but a more general question I have is, are there any tests around access_allow atm?
15:14:25 <vponomaryov> ameade: manila/tests/api/contrib/test_share_actions.py
15:14:59 <ameade> vponomaryov: anything that tests the driver code?
15:15:09 <vponomaryov> ameade: driver tests
15:15:40 <vponomaryov> ameade: all unittests are splited by modules
15:15:55 <ameade> vponomaryov: are there any functional tests?
15:16:05 <vponomaryov> ameade: tempest
15:16:40 <ameade> I'll do a little bit of digging, we can move on with the meeting cknight
15:17:02 <cknight> ameade: ok, please set a concall with vponomaryov if needed
15:17:16 <cknight> #topic Open Discussion
15:17:27 <vponomaryov> cknight: one thing from me
15:18:02 <vponomaryov> cknight: about python-manilaclient project on launchpad
15:18:44 <vponomaryov> cknight: we need to be in charge of it and have possibility to manage bugs and blueprints
15:19:06 <cknight> vponomaryov:  no argument there, who controls it now?
15:19:36 <vponomaryov> cknight:  #link https://launchpad.net/python-manilaclient
15:19:54 <vponomaryov> cknight: Chuck Short
15:20:37 <cknight> vponomaryov:  I see bswartz as the driver & maintainer.  What else do we need to change?
15:20:49 <vponomaryov> try enter bugs or blueprints
15:21:42 <xyang1> Report bug link is disabled
15:21:42 <vponomaryov> cknight: ther is no possibility to manage bugs and blueprint for the moment
15:21:49 <nileshb> One doubt I had while I was trying to understand the current manila functionality - create a share from (another) share's snapshot
15:21:54 <cknight> vponomaryov:  #accept OK, I'll take the action to follow up with bswartz
15:22:03 <nileshb> what would be a typical use-case here?
15:22:41 <deepakcs_> nileshb, typically usecase is the golden image one
15:23:02 <vponomaryov> nileshb: creation share not from scratch but with data from another share
15:23:04 <deepakcs_> nileshb, if u have a share with some data that u want to checkpoint and then offer it as RO to others
15:23:07 <nileshb> the golden image concept works well with cinder
15:23:23 <nileshb> where we cannot attach the same volume to multiple vms
15:23:25 <deepakcs_> nileshb, ya.. i know, but the same analogy can be applied to manila shares
15:23:31 <nileshb> but thats not the case with Manila
15:23:43 <deepakcs_> nileshb, i think cinder does provide a shared volume... iirc
15:23:44 <nileshb> we can mount a single share on multiple instances
15:24:09 <scottda> I don't think Cinder has multi-attach yet
15:24:14 <nileshb> deepakcs: not sure if that feature is merged yet in cinder
15:24:15 <vponomaryov> nileshb: in Manila - just copying data to new share
15:24:25 <deepakcs_> scottda, i thot i saw some 'shared' attr somewhere .. but i may be wrong
15:24:51 <nileshb> then it would be create share from an existing share ... still the use-case is not clear
15:24:53 <deepakcs_> nileshb, creating a new share from snap is like having a new share with the snap's data but no dep on the snap or its original share
15:25:33 <vponomaryov> nileshb: having backup-state share is not use case?
15:25:36 <deepakcs_> nileshb, existign share can have in-flight I/Os and may not be in consistent state. Snaps are supposed to be.. atleast if u want to logically use it later (eg> backup src)
15:25:53 <nileshb> probably restoring the share to a past snap will find better adoption ... well we will need to give more thought to it
15:26:38 <deepakcs_> nileshb, just thinking aloud.. u can snap a finance-dept share on 31st March, and create a new share out of it and give it to audit folks ;-) w/o any dep on orig share
15:26:57 <nileshb> deepakcs_: I agree, so its clone share functionality actually, wherein snapshot is a first step
15:27:14 <deepakcs_> nileshb, yes.. and that is the standard way its done in the storage world
15:27:33 <nileshb> I understand ... we have it in cinder
15:28:15 <deepakcs_> nileshb, the only way to create a new share from a past checkpoint (snap) in a rw way is to use snap
15:28:28 <deepakcs_> and create share-from-snap
15:28:50 <nileshb> deepakcs_: I agree, so we can have a clone_share API, which internally creates a snap
15:29:11 <deepakcs_> nileshb, are u trying to map this to GPFS specifics by any chance ;-) ?
15:29:37 <nileshb> deepakcs_: not really, just thinking aloud :)
15:29:54 <deepakcs_> nileshb, how would clone_share be any different (other than the API name)
15:30:26 <nileshb> basically, wanted to find typical use-case of creating a new share from another share's snapshot ... when you can mount the same original share wherever you want
15:30:45 <nileshb> deepakcs_:but the example you gave for the use-case looks right
15:31:00 <deepakcs_> nileshb, clone share while the share is in use.. isn't a good way
15:31:16 <deepakcs_> nileshb, it might make sense when share is not in use tho'
15:31:32 <deepakcs_> vponomaryov, cknight what do u folks think ^^ ?
15:31:33 <nileshb> it is as well .. but in that case, create share from snap is hidden from user
15:32:09 <vponomaryov> deepakcs_: agree, that share should not be used while snapshoting
15:32:14 <deepakcs_> nileshb, creating a snap under the covers (which takes disk space) isn't good.. u wud create snap, clone, delete snap.. under the covers..
15:32:44 <deepakcs_> vponomaryov, no, nileshb was asking for a new clone_share API which will create a new share (and i was suggesting we can provide that if share is NOT in use)
15:33:18 <cknight> clone_share may make more sense in the context of a workflow that quiesces VMs, creates snaps, etc.
15:33:18 <scottda> Does snapshot work with the generic driver?
15:33:20 <deepakcs_> nileshb, maybe a good topic to discuss on the list.. shoot one :)
15:33:20 <vponomaryov> deepakcs_: from share directly without snapshots?
15:33:44 <deepakcs_> vponomaryov, thats what nileshb was asking.. IIUC
15:34:07 <deepakcs_> cknight, we can already do that in 2 diff steps tho'
15:34:08 <vponomaryov> deepakcs_: I think yes, it makes sense
15:34:24 <nileshb> I meant, clone_share() will internally have an snapshot created anyhow ...
15:34:57 <deepakcs_> nileshb, we already have that.. but we need to use 2 steps... so IIUC all u asking is a 1 step process
15:34:58 <vponomaryov> nileshb: it is upto backend in that case
15:35:15 <vponomaryov> nileshb: no entities in DB, etc
15:35:18 <nileshb> vponomaryov: I agree
15:35:52 <deepakcs_> vponomaryov, good point.. the backend may have features to optimize clone share
15:36:06 <cknight> nileshb: sounds like you can follow up more widely on the mailing list
15:36:15 <nileshb> deepakcs_:exactly
15:36:30 <vponomaryov> nileshb, deepakcs_: agree, cloning/snapshoting shares has a good way for improvement
15:36:32 <deepakcs_> nileshb, and if u have a good example of a backend to justify, pls add to the mail :)
15:36:32 <nileshb> cknight: sure
15:37:05 <cknight> Any other topics for today?
15:37:49 <vponomaryov> cknight: not from me
15:38:14 <cknight> xyang1: any update from your legal team?
15:38:42 <xyang1> cknight: not yet.  they are still looking.  I'm hoping to hear about the decision in mid aug
15:38:54 <cknight> xyang1: ok, thanks
15:38:55 <deepakcs_> any update on the incubation ?
15:39:35 <cknight> deepakcs_:  I haven't heard anything this week.  bswartz is handling that.
15:39:41 <deepakcs_> cknight, np
15:40:28 <cknight> OK, let's call it then.  Thanks everyone!
15:40:35 <cknight> #endmeeting