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