15:01:07 <bswartz> #startmeeting manila 15:01:08 <openstack> Meeting started Thu Jan 19 15:01:07 2017 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:12 <openstack> The meeting name has been set to 'manila' 15:01:12 <bswartz> hello all 15:01:15 <cknight> Hi 15:01:18 <ganso> hello 15:01:18 <gouthamr> hello o/ 15:01:23 <tbarron> hi 15:01:23 <Yogi1> Hi 15:01:24 <vponomaryov> hello 15:01:46 <bswartz> #topic announcements 15:01:59 <bswartz> feature freeze is next week 15:02:15 <jprovazn> hi 15:02:25 <xyang1> hi 15:02:27 <bswartz> as always we're aiming to merge everything by tuesday 15:02:45 <vponomaryov> bswartz: by the end of Tuesday? 15:02:54 <markstur> hi 15:02:55 <gouthamr> bswartz: can we set https://etherpad.openstack.org/p/manila-ocata-code-review-focus in the topic for #openstack-manila 15:03:03 <vkmc> o/ 15:03:08 <bswartz> gouthamr: good idea 15:03:09 <tommylikehu_> hi 15:03:15 <dustins> \o 15:03:28 <tommylikehu_> hey xyang1 15:03:32 <bswartz> vponomaryov: yes if we could have every patch merged by end of Tuesday I'd be thrilled 15:03:40 <tommylikehu_> I just saw your email;( 15:03:51 <xyang1> tommylikehu_: hi 15:04:00 <vponomaryov> bswartz: propheting -> we will not 15:04:08 <bswartz> more realistically we might need to push some things out 15:04:44 <bswartz> we can discuss this more in the next topic 15:05:00 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:05:08 <bswartz> #topic Specs implementation status 15:05:16 <bswartz> #link https://etherpad.openstack.org/p/manila-ocata-code-review-focus 15:05:39 <bswartz> so a few things have been merging, but we're not moving fast enough to hit out target 15:06:29 <bswartz> There are still 6 specs and 2 drivers waiting -- all of these met out deadlines I believe (might need to double check on the new drivers) 15:06:41 <ganso> bswartz: there are driver features as well 15:07:12 <bswartz> there are 4 days including today and next tuesday to merge all of this, so unless we average 2 big patches per day, something will slip 15:07:14 <gouthamr> bswartz: all three met the FPF/Driver deadlines 15:07:38 <bswartz> it's just the reality of how much time we have left 15:07:54 <bswartz> ganso: yes thanks for pointing out that we have some small patches too 15:08:21 <bswartz> let's go over the remaining ones real quick in case we need to discuss any as a group 15:08:39 <bswartz> #topic fix-and-improve-access-rules 15:09:10 <bswartz> I see lots of patch sets and comments here 15:09:13 <gouthamr> being actively reviewed 15:09:13 <bswartz> is it ready? 15:09:37 <bswartz> I haven't reviewed this one -- are we just nitpicking or are there big problems? 15:09:54 <vponomaryov> mostly it is ok 15:10:05 <ganso> LGTM 15:10:25 <bswartz> okay this one is high priority -- let's get it in and move on 15:10:26 <markstur> most is ok 15:10:32 <bswartz> #topic ipv6 15:10:47 <tommylikehu_> well 15:11:07 <gouthamr> i'll help tbarron with reviewing these patches today 15:11:14 <tommylikehu_> thanks 15:11:17 * bswartz curses etherpad 15:11:27 <tbarron> i don't think i'm just nitpicking fwiw 15:11:51 <tommylikehu_> hope it can make it to Ocata 15:11:52 <bswartz> tbarron: on the last one? 15:12:14 <tbarron> yeah, but I'm for the change over all 15:12:18 <gouthamr> tommylikehu_: did you have any other driver patch as well? 15:12:28 <tommylikehu_> no.. 15:12:32 <bswartz> tbarron: if you're not confident your issues can be addressed, let's try to solve the problem, or else we should -2 it an move on to other things that can merge 15:12:47 <tbarron> we are trying to solve 15:12:58 <tommylikehu_> our driver teams are busy with cinder's CI issues 15:13:08 <bswartz> tbarron: I mean let's discuss it in this meeting or in the channel afterwards 15:13:20 <bswartz> back to ipv6 though 15:13:25 <bswartz> this one is next up on my list 15:13:39 <bswartz> tbarron and gouthamr are the official reviewers though 15:13:56 <tommylikehu_> that would be great 15:14:15 <gouthamr> tommylikehu_: okay, thanks... the huawei CI for manila has been flaky and not-reporting or the logs are inaccessible. spoke with a couple of your folks yesterday.. 15:14:24 <bswartz> remember we marked the access rules spec and the ipv6 spec high priority 15:14:45 <tommylikehu_> gouthamr: oh no .. 15:14:58 <bswartz> let's stay on topic guys 15:15:14 <bswartz> #topic eliminate-race-conditions 15:15:28 <bswartz> need another core to sign up to review this 15:16:24 <gouthamr> tbh, this has been around since early newton.. can i help in any way to drive review attention to this? 15:16:26 <xyang1> bswartz: I signed up 15:16:34 <bswartz> xyang1: ty 15:16:46 <gouthamr> thank you xyang1 15:17:10 <bswartz> I'm going to skiup over the drivers, but I'll remark that we need another reviewer for each 15:17:27 <bswartz> xyang1: aren't you doing a lot of the reviews for the new EMC driver? 15:17:42 <xyang1> bswartz: yes, I think it's ready now 15:17:49 <bswartz> #topic mountable-snapshots 15:18:02 <cknight> bswartz: I'm reviewing the EMC driver, too 15:18:18 <bswartz> cknight you're on the etherpad but xyang isn't 15:18:47 <bswartz> ganso/gouthamr/vponomarov how is mountable snapshots 15:18:53 <bswartz> this is another I haven't reveiwed personally 15:19:01 <ganso> this one needs more review attention. There is this snapshot_access helper that hasn't been reviewed at all, and I am trying to address Valeriy's comments, but I find some of them highly unfeasible due to time constraints 15:19:24 <bswartz> ganso: what are you suggesting? 15:19:41 <ganso> I suggest that we discuss some of those unfeasible items 15:19:42 <bswartz> ganso: you want us to compromise on that or are you suggesting we punt on the feature? 15:20:24 <ganso> many of those comments are opposed to what's in the spec, and I personally do not see a problem with them 15:20:26 <bswartz> ganso: is it something we can cover in <5 minutes? 15:20:40 <ganso> bswartz: we can try, I'll try to summarize 15:20:57 <bswartz> oh well if the code does what the spec says we should just merge it 15:21:10 <bswartz> the time for those comments was at spec review time 15:21:11 <vponomaryov> bswartz: spec does not cover lots of places 15:21:13 <ganso> 1) Valeriy suggested that we use the existing export locations table instead of creating snapshot_export_locations table 15:21:14 <bswartz> (in theory) 15:21:25 <bswartz> why does that matter? 15:21:55 <ganso> it is a big refactor to do that ^, and if we plan to do that later, we shouldn't do this now because db migrations will be more complicated in time 15:22:27 <bswartz> vponomaryov: I don't think reuse of a DB table for something like this matters much] 15:22:35 <ganso> 2) Valeriy asked that the snapshot-export-locations and snapshot-instance-export-locations controllers to be merged into the snapshot controller... this is inconsistent with the shares controller 15:22:37 <vponomaryov> what will be better for feature? - it is the question that should be answered 15:22:44 <bswartz> reuse could have some small benefits but it also has some obvious downsides 15:22:46 <gouthamr> let's take that discussion to the review. i agree with ganso here. i don't see the reason to overload. we didn't do this with group type specs when we could have just added another column to extra specs 15:22:47 <ganso> and I personally find the above ^ harder to manage 15:23:36 <bswartz> I think valeriy might be alone in his opinion about (1) 15:24:21 <vponomaryov> it is support of 3 pairs of alike-tables 15:24:30 <vponomaryov> that will be the same all the time 15:24:38 <bswartz> vponomaryov: similar but not necessarily identical 15:24:53 <bswartz> the flexibility to change them independently might matter someday 15:25:03 <bswartz> and if it never does, we could merge them at some future time 15:25:28 <vponomaryov> and ti was a question 15:25:34 <bswartz> okay 15:25:39 <vponomaryov> have it been considered or no 15:26:00 <bswartz> (2) seems to be like another implementation choice which won't matter much in the long run 15:26:39 <bswartz> code reuse is good, but if we overdo it we can build ourselves a straightjacket 15:26:50 <vponomaryov> ganso does not say that it is implemented different way than other alike-nested-objects 15:27:01 <bswartz> controllers for snapshots and shares being different doesn't really bother me 15:27:12 <vponomaryov> 'shares' approach is not ideal 15:27:26 <vponomaryov> speaking from what-we-can-do point 15:27:26 <ganso> to accomplish (2) it would require a lot of effort, it is a major api refactor considering how it is right now 15:27:46 <bswartz> we can't let the perfect be the enemy of the good 15:27:51 <vponomaryov> ganso: it is not 15:28:00 <bswartz> the reality is that it's either good enough now or it's getting punted to pike 15:28:05 <gouthamr> quote of the day :) 15:28:18 <gouthamr> i knew i didn't have to open the forbes website 15:28:51 <ganso> I think we haven't had enough reviewers to call out for "it looks good" or "it is mostly good" 15:28:59 <vponomaryov> in toher words, Rodrigo says "we should merge it as is, no matter how many concers are raised" 15:29:13 <bswartz> I'm okay with punthing things to pike 15:29:50 <ganso> vponomaryov: I didn't say merge as is, I said we need reviewers... I personally do not agree with your 2 requests, but if there are other big requests that I agree with, I'd agree it should be punted to ocata 15:29:54 <bswartz> but in this case it sounds like we'd be doing so for reasons that wouldn't matter at all from an end user perspective 15:29:55 <ganso> *pike ^ 15:30:26 <vponomaryov> bswartz: ok, just mark it as need more eyes 15:30:39 <bswartz> I'm hearing that it's just code beauty issue 15:30:49 <vponomaryov> it is code maintenance 15:31:10 <bswartz> yes maintainability matters, but something merging 2 things which are separate can make code harder to maintain 15:31:20 <bswartz> it's a tough judgement call 15:31:35 <bswartz> s/something/sometimes/ 15:31:41 <vponomaryov> that is why we need more eyes there then ) 15:31:55 <bswartz> okay we'll try to get more eyes on mountable snapshots 15:31:56 <bswartz> let's move on 15:32:01 <bswartz> #topic share groups 15:32:11 <vponomaryov> ready 15:32:24 <bswartz> oh I see markstur just added his name (or someone else added markstur) 15:32:25 <vponomaryov> only xyang had comments, all are resolved 15:32:45 <markstur> yeah. xyang looked lonely 15:32:58 <bswartz> thanks markstur for signing up -- I can also help here but I'm spread a bit thin 15:32:58 <xyang1> I'm going to test it, but so far it looks fine by code inspection 15:33:06 <cknight> vponomaryov: add yourself as a co-author to the client patch 15:33:38 <cknight> vponomaryov: and potentially all of them 15:33:41 <bswartz> #topic migration improvements 15:33:57 <vponomaryov> cknight: actually, even in server side I was "writing" some parts from scratch 15:34:02 <bswartz> personally I care more about this one than mountable snasphots 15:34:28 <ganso> it is ready, just your comments are the last ones to be addressed, I am waiting for your response on some of them. Some of them touch decisions made far back in the past about share instances 15:34:32 <gouthamr> Yogi1 and I are testing migration improvements - afaics LGTM, we need test results that we'll post soon 15:34:52 <bswartz> It was pointed out to me today that snake_case is actually preferred to hyphen-case so I'm going to withdraw those comments 15:35:11 <ganso> the comment about showing "error" snapshot instances 15:35:27 <ganso> it is valid based on the fact that the user needs to get rid of the error status in order to migrate 15:35:55 <bswartz> okay I'll take another look at this today 15:35:56 <ganso> but we decided back then that when we have multiple instances, we only show the available or, more importantly, the active one that is under a transitional status 15:35:59 <gouthamr> ^ tbarron this relates to our discussion around share and share instance proxying too 15:36:16 <tbarron> yes 15:36:16 <bswartz> ganso: let's keep that conversation going in PMs 15:36:21 <ganso> bswartz: ok 15:36:57 <bswartz> I should point out that we have 2 netapp ppl signed up to review this and under our rules that's not enough to merge it 15:37:17 <tommylikehu_> what is ppl 15:37:23 <ganso> tommylikehu_: people 15:37:23 <vponomaryov> people ) 15:37:26 <gouthamr> tommylikehu_: people 15:37:28 <bswartz> so if we can get a 3rd reviewer that would be great 15:37:33 <tommylikehu_> thanks 15:37:49 <ganso> markstur and vponomaryov have contributed to reviewing migration 15:37:54 * gouthamr gah, should have told tommylikehu_ that it stands for someone uber cool 15:37:57 <ganso> xyang1 as well 15:38:07 <vponomaryov> ganso: tsss 15:38:07 <bswartz> we'll just need an extra +2 before we can workflow 15:38:28 <bswartz> otherwise it will technically be a ninja merge of a major feature, which is bad 15:39:03 <bswartz> alright that's it 15:39:47 <bswartz> I'll say briefly that I have a good feeling about the specs process so far -- it's put a limit on how much stuff we've had to look at 15:39:47 <markstur> that was easy 15:40:01 <gouthamr> yeah it only took 40 mins 15:40:16 <bswartz> I think I'd debatable whether we set the limit too high but we will revisit that question after FF 15:40:38 <bswartz> okay ravichandran threw out a bunch of questions 15:40:47 <bswartz> #topic Filterscheduler warning in logs 15:40:53 <bswartz> ravichandran you here? 15:41:06 <bswartz> "WARNING manila.scheduler.manager [-] Scheduler driver path manila.scheduler.filter_scheduler.FilterScheduler is deprecated, update your configuration to the new path manila.scheduler.drivers.filter.FilterScheduler " 15:41:28 <bswartz> this looks like an issue with the default value being deprecated? 15:41:34 <gouthamr> ^ we didn't have release notes back then... 15:41:52 <tbarron> probably it's time to clean that one up 15:41:53 <bswartz> well I'm wondering if devstack has a bug 15:42:11 <gouthamr> also, it's deprecated for over a release now.. we should remove the compatibility code 15:42:27 <bswartz> we should make sure we're not using the deprecated value first 15:42:33 <tbarron> yeah, you said what I was trying to saY, gouthamr 15:42:57 <markstur> bswartz: +1 15:43:00 <bswartz> most of us ignore that kind of log spam I think 15:43:11 <bswartz> but it's an indication of a bug waiting to happen, so let's deal with it 15:43:18 <vponomaryov> such kind of thing just should be proposed as gerrit patch, nothing to discuss IMHO 15:43:42 <bswartz> yeah the issue is that ravichandran doesn't know that so we're telling everything 15:43:56 <bswartz> and since ravichandran isn't here we'll skip the rest of his topics 15:43:57 <tbarron> and right after FF is a good time for such changes 15:44:02 <gouthamr> +1 15:44:18 <bswartz> #topic PTG 15:44:32 <bswartz> #link https://etherpad.openstack.org/p/manila-pike-ptg-topics 15:44:46 <bswartz> we are still collecting topics 15:44:46 <gouthamr> "How to see the recently committed changes to (master branch ) /config-reference/shared-file-systems/drivers/hpe-3par-share-driver.html in docs.openstack.org.(ravichandran)" -> http://docs.openstack.org/draft/config-reference/ 15:44:59 <bswartz> add them to the etherpad as they come up 15:45:18 <bswartz> gouthamr: just email/PM him directly 15:45:58 <bswartz> PTG is just a month away 15:46:29 <tommylikehu_> tbarron: what is VMT process? 15:46:48 <bswartz> next week we'll give more time to PTG stuff but just reminding you to update the etherpad with topics that come up during code reviews, etc 15:46:56 <bswartz> #topic open discussion 15:47:10 <tbarron> tommylikehu_: edited etherpad 15:47:18 <bswartz> okay we have some time to cover anything else 15:47:40 <bswartz> we can go into more detail on issues with new features if we need to 15:48:11 <ganso> we can discuss that one that snapshot instance 'error' status now if you prefer 15:48:27 <bswartz> ganso: I dunno if anyone else is interested in that 15:48:34 <bswartz> but if it's all we have, go ahead 15:48:55 <gouthamr> tbarron and i are... i think its a bigger topic for the ptg 15:49:06 <ganso> so, you commented that ERROR status for snapshot instance should be shown instead of available 15:49:11 <bswartz> yes 15:49:21 <ganso> because the user has to get rid of those in order to migrate 15:49:35 <bswartz> if you have multiple instances and one of them is in an error state, it seems like the whole object must be in error too 15:49:51 <ganso> but back then, we decided that we do not care about instances in those status unless they are the sole/active instance 15:50:05 <bswartz> that's a signal that an admin needs to go clean something up to return that share/snapshot to a healthy state 15:50:46 <ganso> yes, but in replication, and you do a manila list, why would you list that one if the active instance is "available" ? 15:52:10 <ganso> this, in fact, brings up the 2nd part of my question, which is, what does error represent? can we just ignore instances in 'error' status? would be a proper solution for me to code in migration to migrate and delete the error'ed ones that are left behind? I am concerned about possible data loss, if there is any data associated with those snapshot instances 15:52:40 <bswartz> okay maybe this is the key 15:52:59 <bswartz> we shouldn't use error if it's something that can be safely ignored 15:53:31 <bswartz> error should be for when something needs admin attention 15:53:53 <bswartz> for replication we have the concept of "out of sync" replicas 15:53:57 <gouthamr> ganso: we no longer ignore error-ed instances in the access-rules API 15:54:10 <gouthamr> ganso: maybe it's a question per action... 15:54:19 <bswartz> those are temporarily unusual but will eventually self-heal and become usable again 15:54:24 <ganso> gouthamr: we still do wrt share instances 15:54:37 <ganso> gouthamr: and there's possibly data in those instances 15:54:37 <tbarron> 'untable' ? 15:54:41 <bswartz> s/unusual/unusable/ 15:55:03 <gouthamr> bswartz: yes, those replicas will never go to error 15:55:10 <tbarron> 'unstable' I mean, as a replacement for 'error' when it is temporarily unusable? 15:55:20 <bswartz> IMO a migration error absolutely needs to be cleaned up before you can do more with that share 15:55:50 <ganso> bswartz: it is a previous snapshot instance in error status, before issuing migration-start 15:55:51 <bswartz> ignoring an error in a migration and trying to continue to operate on that share seems like it will lead to data loss with high probability 15:56:22 <bswartz> what do you mean "previous"? 15:56:33 <bswartz> when you start migrating you only have 1 instance 15:56:42 <ganso> bswartz: like, an existing snapshot with 2 instances 15:56:47 <bswartz> and that instance is either healthy or not healthy 15:56:53 <bswartz> ganso: how could that happen? 15:57:05 <ganso> bswartz: driver assisted migration 15:57:24 <bswartz> those instances are created after you start the migration I thought 15:57:40 <ganso> bswartz: it is true that we do not support migration of replicated shares 15:58:10 <ganso> gouthamr: is there any way to have more than one snapshot instance on a non-replicated share? 15:58:27 <bswartz> IMO the only way you can end up with error snapshot instance is if you already tried and failed to do a migration with preserve-snapshots 15:58:38 <ganso> bswartz: the destination instance is, but we are still consider one instance 15:58:42 <bswartz> and in that case you need to completely clean up the error before you can proceed 15:59:08 <ganso> bswartz: yes, that scenario is handled 15:59:23 <ganso> bswartz: I thought your comment was more generic 15:59:31 <bswartz> so we can agree then that errors are always fatal and error status should appear first in the sort list 15:59:57 <ganso> bswartz: but we don't care about the destination instance 16:00:03 <bswartz> non-fatal conditions should be called something other than error 16:00:09 <ganso> bswartz: the source/active instance must remain in available status 16:00:21 <ganso> bswartz: when migration fails and it is aborted, the destination instance is cleaned up 16:00:40 <ganso> bswartz: the only case not cleaned up is when migration-complete fails during a driver-assisted migration 16:00:45 <bswartz> k 16:00:47 <gouthamr> time check 16:01:30 <bswartz> sorry my phone rang 16:01:34 <bswartz> #endmeeting