15:00:09 <bswartz> #startmeeting manila
15:00:10 <openstack> Meeting started Thu Apr 30 15:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:13 <openstack> The meeting name has been set to 'manila'
15:00:15 <cknight> Hi
15:00:18 <ganso__> hello
15:00:19 <bswartz> hello
15:00:20 <Zhongjun> hi
15:00:25 <zongliang> Hi
15:00:26 <vponomaryov> hello
15:00:32 <xyang1> Hi
15:00:32 <gary-smith> hi
15:00:35 <u_glide> hello
15:00:40 <weiting> Hi
15:00:47 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:20 <bswartz> #topic announcements
15:01:39 <bswartz> welcome markstur and toabctl to core reviewer team
15:01:42 <lpabon> hi
15:01:46 <csaba1> hi
15:01:47 <cknight> congrats, guys!
15:01:50 <bswartz> thanks for all your help with reviews during kilo
15:02:19 <bswartz> #topic Liberty design summit planning
15:02:30 <bswartz> so kilo is releasing today
15:02:56 <markstur> hi
15:02:59 <zongliang> good
15:03:04 <bswartz> we didn't have any last minute bugs, other than the glusterfs/multibackend bug which we decided to postpone until liberty
15:03:38 <bswartz> now we can turn our focus completely to liberty
15:03:39 <ganso__> we found a Share DB bug... I do not know the impact besides share_migration
15:03:51 <bswartz> #link https://etherpad.openstack.org/p/manila-liberty-proposed-sessions
15:04:05 <ganso__> either way it does not look like something difficult to work around
15:04:08 <vponomaryov> ganso__: you mean 'export_location' one?
15:04:11 <bswartz> ganso__: please file it in LP, and if you think it's worth of a backport please tag it with kilo-backport-potential
15:04:13 <ganso__> vponomaryov: yes
15:04:17 <bswartz> worthy*
15:04:25 <vponomaryov> no, it does not worth backport
15:04:38 <ganso__> I have not filed because it only affects me at this moment, and share_migration is for liberty
15:04:39 <u_glide> vponomaryov: +1
15:04:45 <bswartz> ok
15:05:13 <bswartz> the comment about taking for backport applies to everyone -- if you find a bug in liberty that should also be fixed in kilo, "kilo-backport-potential" is the tag to use
15:05:21 <bswartz> s/taking/tagging/
15:06:00 <bswartz> so I finally added my design summit proposal ideas to the etherpad
15:06:22 <bswartz> since I can't attend in person, I'll be looking for other people to do the proposals/presentations on my behalf
15:07:03 <bswartz> today we're going to go through this list and make sure we have names next to all of the topics and we'll gauge interest so I can figure out how to schedule all the topics
15:07:11 <bswartz> starting at the top
15:07:17 <bswartz> Relationship between shares and snapshots [2] (lpabon)
15:07:24 <lpabon> yep
15:07:31 <bswartz> can you explain this proposal?
15:07:46 <lpabon> now, or on the pad?
15:07:56 <bswartz> ideally both
15:08:23 <lpabon> sure, what i would like to discuss is what are the responsabilites between the API and drivers
15:08:54 <bswartz> so everyone know that currently snapshots are associated with shares, and you can't delete a share which still has snapshots
15:08:55 <lpabon> The name of in the pad comes from a review which makes descision on snapshots at the API level.
15:09:06 <bswartz> (I hope everyone knows that)
15:09:15 <bswartz> do you propose to change that fact?
15:09:40 <lpabon> So, my discussion is to use that as a starting point but mainly to discuss what are the responsabilities of the API and the drivers
15:09:48 <xyang2> I believe this is about whether to delete volume when there are still snapshots?
15:09:55 <bswartz> s/volume/share/
15:10:05 <xyang2> bswartz: thanks:)
15:10:10 <lpabon> if the API decides to take some action, it could cause some drivers to not be able to use their "special" technology
15:10:22 <lpabon> that's the heart of the discussion
15:10:49 <markstur> if you want the discussion to be that general probably should have a different topic proposed
15:10:49 <lpabon> that's it
15:11:08 <lpabon> I could change the topic title
15:11:22 <bswartz> lpabon: yeah please describe on the etherpad what you said
15:11:26 <lpabon> np
15:11:39 <bswartz> and also did you intend this as a fishbowl topic or a working session topic?
15:12:04 <lpabon> its really up to you guys.. what do you guys suggest?
15:12:07 <bswartz> my gut feeling is that this might take less than a whole session
15:12:13 <bswartz> so it's a candidate for combining
15:12:22 <lpabon> I'm ok with either
15:12:26 <bswartz> but if there is high interest, we can dedicate a session
15:12:40 <cknight> bswartz: +1, combine this one withe something else
15:13:39 <bswartz> we'll gather feedback on interest level later
15:13:41 <bswartz> next topic
15:13:47 <bswartz> Share Migration [5] ( https://blueprints.launchpad.net/manila/+spec/share-migration ) (ganso)
15:14:24 <bswartz> I made another proposal lower down called "Manila data copying service" which is related
15:14:43 <bswartz> this topic was also discussed at the midcycle
15:15:17 <bswartz> ganso__ should be present to propose this, and I'll work with him before the summit to incorporate the 2 ideas
15:15:18 <ganso__> regarding Share migration, I proposed fishbowl because the prototype is 80% coded at this moment, as far as I know working sessions are for coding, I have more stuff to present than to code, so I was thinking about a presentation/discussion/quick live-review, gather suggestions and improvements
15:15:24 <bswartz> is it clear what the proposal is?
15:16:14 <bswartz> ganso__: working sessions aren't literally for writing code -- but they're more intimate and we might present/examine the code itself
15:16:57 <ganso__> I don't there is that much code for a working session
15:17:06 <ganso__> but it can be a working session, no problem
15:17:10 <bswartz> I can see this one as a fishbowl session -- it's a major new feature
15:18:31 <bswartz> okay next topic
15:18:36 <bswartz> Manage/unmanage snapshot (https://blueprints.launchpad.net/manila/+spec/manage-unmanage-snapshot)  (xyang)
15:18:46 <xyang2> we already have manage/unmanage share
15:18:59 <xyang2> so it is the natural next step to introduce this for snapshots
15:18:59 <bswartz> xyang2: you're going to present?
15:19:02 <xyang2> yes
15:19:21 <bswartz> xyang2: is there a corresponding proposal for cinder?
15:19:27 <xyang2> yes
15:19:42 <bswartz> okay
15:19:43 <xyang2> code is being reviewed. almost ready.  missed kilo
15:19:56 <bswartz> the unmanaging makes sense to me -- you have a plan for managing too?
15:20:05 <xyang2> yes
15:20:05 <vponomaryov> xyang2: reviewed internally?
15:20:16 <bswartz> snapshots would need to be associated with a share somehow
15:20:21 <xyang2> vponomaryov: I mean the cinder patch
15:20:33 <vponomaryov> xyang2: ah, ok
15:20:38 <xyang2> the cinder patch for manage/unmanage snapshot is there being reviewed
15:20:39 <bswartz> unless lpabon finds a way to help us break that association
15:20:55 <xyang2> bswartz: yes, the share has to be there first
15:21:05 <bswartz> ok
15:21:10 <xyang2> bswartz: we'll be looking at Cinder's implementation
15:21:22 <bswartz> fishbowl session? you think you need the full 40 minutes?
15:21:28 <lpabon> xyang2: that sounds like a good idea
15:21:41 <xyang2> bswartz: I don't think I need 40 minutes, can combine with something else
15:21:52 <bswartz> Oh I see
15:22:04 <xyang2> it is relatively straight forward
15:22:10 <bswartz> yes it makes sense -- the share-to-snapshot relationship in manila has to mirror was actually exists on the backend in any case
15:22:45 <bswartz> okay
15:23:01 <bswartz> Manila support Qos (https://blueprints.launchpad.net/manila/+spec/manila-support-qos) (zhongjun)
15:23:18 <Zhongjun> I hope Manila support Qos in L.
15:23:36 <bswartz> Zhongjun: are you going to present this in vancouver?
15:23:40 <zongliang> Me two
15:24:04 <Zhongjun> sorry, I can't attend in vancouver.
15:24:37 <bswartz> Zhongjun: is there someone from Huawei who can present on your behalf?
15:25:05 <bswartz> I think QoS is an important topic, but for it to be a design summit topic someone needs to take it up and drive the session
15:25:46 <bswartz> we can look for volunteers if needed -- and it doesn't have to be right now -- but we'll need to get someone to sign up soon
15:26:33 <bswartz> Zhongjun: I see there is a BP with some details
15:26:43 <bswartz> any functional spec or additional docs?
15:26:53 <li_zhang> This time there will be only some marketing guys from huawei to attend th summit.../
15:27:02 <zongliang> May be we can discuss in the meeting and design it use the witeboard
15:27:06 <Zhongjun> OK, I try to looking for a volunteers.
15:27:13 <bswartz> I'll look as well
15:27:23 <bswartz> I know many people want to see QoS support happen
15:27:37 <li_zhang> yes
15:28:24 <bswartz> also it doesn't have to be discussed at the design summit for it to get done -- if the BP is good and the code is good we can still review it and merge it
15:28:44 <bswartz> but something like a major new feature should be discussed in a large forum like the summit if possible
15:29:18 <bswartz> I'll skip my data copying service -- and try to get ganso to work it into his proposal
15:29:30 <bswartz> Data replication (cknight)
15:30:01 <bswartz> cknight: did you want to present this?
15:30:07 <cknight> bswartz: It's a big topic, but I'm good to present it.
15:30:20 <bswartz> okay
15:30:32 <bswartz> some of you may be aware that this has been a long running topic in cinder, with not such a good history
15:31:18 <xyang2> there are major rework going on with replication in cinder.  I think it is a good idea to look at the result of the WIP replication v2 in cinder
15:31:21 <bswartz> I hope we can avoid the same fate by getting the design nailed down and getting everyone to agree early in the release
15:31:37 <cknight> bswartz: replication potentially dovetails with mount automation
15:31:50 <markstur> xyang2, Will there be a Cinder working session dedicated to repl
15:32:01 <xyang2> markstur: yes
15:32:08 <bswartz> xyang2: I agree, as long as the cinder proposal is less controversial this time around
15:32:17 <xyang2> bswartz:  :)
15:32:27 <xyang2> bswartz: + CG
15:32:44 <bswartz> somehow we always hope that cinder replication will work, but then during the design discussions a bunch of problems pop up
15:33:26 <xyang2> bswartz: have you looked at the WIP cinder spec for v2?
15:34:00 <bswartz> xyang2: I did some time ago -- I haven't been following it closely
15:34:18 <bswartz> that's something we should do before making the proposal for manila DR
15:34:32 <xyang2> bswartz: I hope we can settle down at the summit
15:34:44 <bswartz> to see if any good ideas can be stolen, or if we forgot anything important
15:35:01 <bswartz> Manila DR will necessarily have a different flavor than Cinder DR, but the core idea is the same
15:35:09 <xyang2> bswartz: sure
15:35:36 <bswartz> okay
15:35:53 <bswartz> mount automation (me)
15:36:12 <bswartz> I added this, but I won't be presenting it
15:36:33 <bswartz> we still have too many ideas and not enough focus in this area
15:36:52 <bswartz> so we're actively working on narrowing it down to something concrete and achievable
15:37:18 <bswartz> this topic can't be left out though, given how much interest there has been in past summits
15:37:39 <bswartz> sage: you added a note about mount automation
15:37:47 <bswartz> +1 for a nova API (attach-filesystem, detach-filesystem).  this would require a nova agent (e.g., qemu-guest-agent) to do some work.  other drivers (e.g., lxc or nova-docker) could mount on the host and do a simple bind mount into the container namespace. <sage>
15:38:06 <bswartz> did you have a proposal to make, or just supporting that approach?
15:38:37 <sage> supporting that approach.  no code at this point
15:38:56 <bswartz> okay
15:39:06 <bswartz> the nova API approach has come up in the past -- at the midcycle in fact
15:39:19 <sage> haomai has worked on a prototype that overloads the existing attach-volume with a 'type' field, but my guess is that a set of calls would be better received
15:39:21 <sage> ?
15:39:47 <bswartz> dalgaaf wanted to use virtfs to attach filesystems to guests, and we agreed that a nova API would be the right way to do that
15:40:10 <bswartz> an extension to nova, rather, with a new API
15:40:38 <sage> yeah.  my hope ist hat the api could do a virtfs attach, or nfs reexport from host, or a bind mount if it is a container (not vm)
15:40:55 <bswartz> yeah containers add a whole new dimension to the mounting/attaching problem
15:41:07 <lpabon> the only difference would be that the API would need to be applied to N diff VMs, while volumes today are only attached to a single VM
15:41:23 <bswartz> lpabon: yes
15:41:34 <bswartz> okay next topic
15:41:38 <bswartz> Service Image (lpabon-- I think I wrote this one..)
15:41:43 <sage> yeah.  the part i'm struggling with is the final "mount" step.  with a container it bind mounts it into the namespace, bu tin most other cases we aren't (currently) using an agent to do the mount -t whatever.
15:42:04 <lpabon> sage: yeah, difficult
15:42:11 <lpabon> bswartz: yeah I wrote that one
15:42:13 <bswartz> lpabon: I'm guessing from your comment that you're not presenting this?
15:42:26 <lpabon> bswartz: It is really a discussion.
15:42:29 <bswartz> do you have a proposal? or just want us to talk about it
15:42:48 <bswartz> this one feels more working session appropriate to me
15:42:48 <sage> best idea i've come up with is to bind mount to /dev/manila/foo (or something "dev-like") so that the admin/user would still do a final mount (in this case, another mount --bind inside the container)
15:42:50 <lpabon> I would like to discuss how do we standardize on what a service vm is
15:43:01 <sage> would love to discuss this in a working session in vancouver :)
15:43:20 <bswartz> sage: it's likely to be a session
15:43:26 <lpabon> My main concern is around service vm management and upgrades
15:43:39 <bswartz> at the end of this meeting I'm going to ask everyone to register their interest on the etherpad
15:43:52 <lpabon> I do have some suggestions, but I would like to discuss it with the group
15:43:57 <bswartz> lpabon: so maybe you can guide the discussion?
15:43:59 <sage> i'm not likely to write any code here, but i'm happy to talk about it
15:44:05 <lpabon> bswartz: sure
15:44:16 <bswartz> csaba was involved with the service image discussion in paris
15:44:28 <bswartz> csaba will you also make vancouver?
15:44:55 <bswartz> Thin provisioning/oversubscription (bswartz)
15:45:16 <xyang2> bswartz: I can talk about this one if you want
15:45:20 <csaba1> bswartz: I won't be there :(
15:45:21 <bswartz> so this is another idea from cinder -- xyang I didn't know if you had any interest in carying that work over to manila
15:45:42 <xyang2> bswartz: yes, I do have interest
15:45:55 <bswartz> it's not a high priority for me, given the other topics, but I wanted to throw it out there in case others had strong feelings
15:46:39 <bswartz> okay
15:46:43 <bswartz> Share retype (bswartz)
15:47:00 <bswartz> this is another feature from cinder, which would rely on the migration feature
15:47:14 <bswartz> ganso: don't know if you want to include this one
15:47:35 <bswartz> it's pretty valuable though for tenants to be able to change the type of their shares
15:48:04 <bswartz> and given that migrations are typically administrator-initiated, retyping is one of the few cases when a migration would be triggered by a tenant action
15:48:48 <bswartz> this discussion could also wait until after we have migration nailed down
15:48:55 <ganso__> Migration is a pre-requisite for re-type
15:49:06 <bswartz> okay I'll run through the proposed working sessions fast because we're short on time
15:49:07 <ganso__> I have taken a look at it, but it is quite big
15:49:19 <ganso__> I have given up including it in the prototype
15:49:31 <bswartz> ipv6 support is just a maintenance/testing thing
15:49:37 <ganso__> in the Share_migration prototype
15:49:41 <bswartz> someone needs to drive it though
15:49:47 <bswartz> API versioning (extensions, microversions, etc.) (cknight)
15:50:02 <bswartz> we've discussed this and we need to decide on a strategy or continue to deal with the mess we have
15:50:22 <bswartz> not a sexy topic, but necessary
15:50:27 <bswartz> Fault indications (cknight)
15:50:44 <cknight> bswartz: faults is really Alex's thing
15:50:45 <bswartz> I think ameade is proposing fault indications in cinder
15:51:01 <cknight> bswartz: +1, let's watch that space
15:51:17 <bswartz> we might want to let the cinder team work out this topic
15:51:33 <bswartz> Versioned objects (weiting <weiting.chen@intel.com>)
15:51:42 <xyang2> bswartz: are working sessions supposedly include only developers while fishbowl will have users in addition to developers?
15:51:43 <weiting> Hi
15:51:55 <weiting> I will go to vancouver and give a present for this topic
15:52:04 <ameade> bswartz:  just proposed it for cross project
15:52:10 <bswartz> xyang2: working session is just a smaller space with a table instead of a circle of chairs
15:52:22 <bswartz> weiting: awesome!
15:52:29 <weiting> The main contributor would be Li Chen.
15:52:38 <bswartz> weiting: and your proposed application is rolling upgrade, correct?
15:52:44 <weiting> Currently we are working on the same topic for Sahara
15:53:22 <bswartz> lastly, 3rd-party CI is listed as a topic
15:53:42 <weiting> And we are discussing with another contributor who is writing the versioned object architecture for Heat.
15:53:49 <u_glide> weiting: Do you plan to cover NoSQL db support ?
15:53:51 <bswartz> I'm not sure this needs design summit time -- I think we can manage this one on the ML and through the regular meetings
15:54:08 <xyang2> weiting: versioned object is in cinder too
15:54:10 <weiting> Actually this implementation is still not clear
15:54:16 <bswartz> however HP has volunteered to talk about it, so if there is interest we could do a session on it
15:54:24 <weiting> That is why we need to discuss it
15:54:37 <markstur> folks could also just go watch a session about it
15:54:50 <markstur> I was just thinking we might all discuss it together
15:55:02 <bswartz> so in our last 5 minutes, I'd like everyone to open the etherpad and put +1s next to the topics that you personally want to see discussed
15:55:11 <bswartz> #link https://etherpad.openstack.org/p/manila-liberty-proposed-sessions
15:55:39 <weiting> It's welcome to add all the question in etherpad for versioned objects
15:56:05 <bswartz> please don't put +1 next to everything, just the top things you want to see
15:56:35 <bswartz> errr, I just realized I skipped Consistency groups
15:56:57 <bswartz> that's another fishbowl topic proposal
15:57:05 <xyang2> bswartz: that can go with replication
15:57:36 <bswartz> yeah assuming we don't have enough space for all the sessions I'm going to work on squeezing them together over the next week, and making sure we have commitments from presenters
15:58:24 <markstur> +1 for all of them
15:58:34 <bswartz> also remember that you're voting for the feature to be discussed, not for the feature to go into manila
15:58:54 <markstur> We should have a list of things that we'll talk about _if_ we have time
15:58:56 <bswartz> some things are non-controversial and we can just work on them without spending time at the design summit
15:59:11 <markstur> but that makes it tough to have someone prepared to maybe lead -- unless it is wing-it-able
15:59:12 <bswartz> markstur -- we'll have a backup agenda for sure
15:59:35 <bswartz> in case sessions end early and people want to dive into another topic -- that happens from time to time
15:59:54 <markstur> mount automation is trending again
16:00:02 <xyang2> bswartz: replication and cg are guaranteed to be very controversial:)
16:00:03 * bswartz is unsurprised
16:00:30 <bswartz> xyang2: I hope not!
16:00:48 <xyang2> bswartz: look at how many comments are left in replication v2 spec:)
16:00:50 <bswartz> if the proposal is good, then everyone will love it, right?
16:01:00 <xyang2> bswartz: I still have a ton that I like to bring up
16:01:12 <bswartz> okay
16:01:14 <bswartz> we're past time
16:01:35 <bswartz> please vote in the etherpad if you haven't, and make sure you have a name in etherpad so we can track who voted (no ballot box stuffing!)
16:01:41 <bswartz> thanks all
16:01:50 <bswartz> #endmeeting