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