15:00:06 <bswartz> #startmeeting manila
15:00:07 <openstack> Meeting started Thu Jan  5 15:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:10 <openstack> The meeting name has been set to 'manila'
15:00:13 <bswartz> hello all
15:00:23 <tommylikehu_> happy new year
15:00:28 <tbarron> hi
15:00:32 <markstur_> hi
15:00:37 <bswartz> yes happy new year!
15:00:45 <bswartz> at least happy solar new year
15:00:57 <bswartz> I know lunar new year is coming some time soon
15:01:22 <dustins> \o
15:01:24 <tommylikehu_> bswartz: yes!
15:01:39 <bswartz> ganso cknight xyang toabctl gouthamr: courtesy ping
15:01:56 <xyang1> hi
15:02:40 <bswartz> we might not have a quorum today...
15:02:49 <bswartz> people still on extended vacations maybe
15:03:08 <ganso> hello
15:03:13 <tommylikehu_> https://wiki.openstack.org/wiki/Manila/Meetings
15:04:31 <tommylikehu_> we have topics there
15:04:47 <bswartz> well we have 5/9 on the core team -- let's call that a quorum
15:05:09 <bswartz> #topic announcements
15:05:25 <bswartz> next week is feature proposal freeze
15:06:03 <bswartz> that means all features need to be proposed in gerrit, substantially complete, and passing tests
15:06:35 <tommylikehu_> including the high priority ones?
15:06:46 <bswartz> yes everything
15:07:13 <bswartz> after that we only accept bugfixes, doc changes, and trivial changes
15:07:29 <bswartz> given how short this release is it won't surprise me if a lot of things don't make it
15:08:00 <bswartz> I haven't been able to dedicate enough time to the things with my name on them
15:08:09 <tommylikehu_> if the one of the feature patches can not meet the requrement, does that means all the patches should not be merged?
15:08:28 <bswartz> tommylikehu_: no we'll consider things on a patch-by-patch basis
15:08:39 <bswartz> however if there are dependency chains we have to merge them in order
15:08:45 <tommylikehu_> bswartz:  thanks
15:09:05 <bswartz> and we won't do things like merge a feature that has no test coverage
15:09:25 <ganso> what if it is only the client or ui that needs further work?
15:09:35 <bswartz> ganso: I have worse news there
15:09:46 <bswartz> actually I don't
15:09:56 <tommylikehu_> bswartz: I think no core member would press the +2 button with that
15:09:56 <ganso> bswartz: o_O
15:10:10 <bswartz> the client and UI are both exempt from the non-client-library freeze which is also next week
15:10:44 <bswartz> err
15:10:47 <ganso> bswartz: does this mean that there is not deadline for client and UI?
15:10:52 * bswartz shakes head
15:11:00 <bswartz> I need to stop spreading misinformation
15:11:07 <bswartz> the non client library freeze is in 2 weeks
15:11:32 <bswartz> and our client and ui are except from that freeze, meaning they have the same deadlines as manila itself
15:11:53 <tommylikehu_> ok
15:11:55 <bswartz> ganso: does that answer your question?
15:12:10 <ganso> bswartz: I am a bit confused
15:12:11 <bswartz> s/except/exempt/
15:12:33 <ganso> bswartz: does this mean that client/UI patches that add features could popup after non-client feature freeze?
15:13:01 <bswartz> no, it means we have until next week to propose them, and 3 weeks until they must merge
15:13:25 <ganso> bswartz: so, deadlines are the same
15:13:33 <bswartz> yes that's what I was trying to say
15:13:41 <bswartz> the non-client-library freeze is a red herring
15:14:02 <bswartz> however people should be aware that it exists, in case you work on anything outside manila
15:15:14 <bswartz> alright let's move on to the agenda then
15:15:19 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:15:36 <bswartz> #topic Specs implementation status
15:16:13 <bswartz> #link https://etherpad.openstack.org/p/manila-ocata-code-review-focus
15:16:36 <bswartz> so the access rules patch is not ready it seems
15:16:55 <bswartz> gouthamr has been on vacation and should return today/tomorrow
15:17:09 <tommylikehu_> great
15:17:22 <bswartz> ipv6 has a lot of patches
15:17:48 <bswartz> tommylikehu_: anything you want to share about this?
15:18:06 <tommylikehu_> about what?
15:18:13 <bswartz> about this feature
15:18:19 <tommylikehu_> maybe I need more review from all of you :)
15:18:32 <tommylikehu_> especially for the generic driver part
15:18:33 <bswartz> can you briefly tell us how much it's complete and what's left to be done?
15:19:02 <tommylikehu_> except for the generic driver patch and documentation
15:19:03 <bswartz> tommylikehu_: just the 4 patches listed on that etherpad?
15:19:08 <tommylikehu_> others are ready
15:19:28 <bswartz> k
15:19:33 <tommylikehu_> there are five
15:19:43 <tommylikehu_> I will add the last one later
15:20:02 <bswartz> tommylikehu_: thx -- we will continue to use this etherpad until feature freeze
15:20:13 <tommylikehu_> ok
15:20:27 <bswartz> regarding the race conditions work, we still need to get tooz support merged before that can move forward
15:20:38 <bswartz> I'm one of the reviewers for that
15:20:42 <bswartz> we need another
15:21:22 * bswartz hopes his py3 issues are sorted out
15:21:31 <tommylikehu_> if you add me there, I'd like to give +1 two times
15:21:42 <bswartz> lol
15:21:48 <tbarron> rofl
15:22:44 <bswartz> seriously though, +1s are still very valuable if you review the code and actually tests it and see that it works
15:22:48 <bswartz> regarding scenario tests, it looks like the patch merged, and I'm not sure if there are any more patches coming from vponomaryov
15:23:25 <bswartz> create-share-from-snapshot extra spec is done I believe
15:23:33 <tbarron> can we extend the deadline on race conditions on the grounds that it is fixing real bugs more than adding features?
15:23:45 <tbarron> feature: we don't break so bad
15:24:09 <bswartz> the revert to snapshot work should be rebased and ready for review now (I think)
15:24:22 <tommylikehu_> yes
15:24:26 <tbarron> bswartz: yeah, I'm actively reviewing that one
15:24:26 <bswartz> tbarron: fixing race condition bugs can happen at any time
15:24:53 <bswartz> tbarron: however the spec calls for adding new features to make it easier to fix bugs and I wouldn't feel safe adding new features after feature freeze
15:25:39 <tbarron> bswartz: that spec calls for drivers to return per-rule success and failure; right now we don't have a way to do that if the driver raises an exception, right?
15:26:17 <bswartz> tbarron: I think you're talking about access rules not race conditions
15:26:24 <tbarron> looks like the implementation is currently just setting all rules to fail
15:26:36 <tbarron> yes, sorry, race conditions in access rules
15:27:08 <bswartz> It's unlikely that we can get drivers to make changes before release
15:27:34 <bswartz> if we need to improve the driver interface, we can do it before feature freeze, but it must be backward compatible to avoid breaking existing drivers
15:28:36 <bswartz> tbarron that topic probably needs more discussion
15:28:46 <bswartz> Ideally gouthamr would be heref or that
15:29:40 <bswartz> let's continue with this topic
15:29:44 <bswartz> mountable snasphots has a bunch of patches I see
15:30:24 <bswartz> tpsilva, ganso: how is this effort?
15:30:35 <ganso> implementation is complete, it just needs more testing
15:30:44 <ganso> sorry, more tempest tests
15:30:53 <ganso> ideally, mountable snapshots should handle migrating snapshots
15:31:00 <ganso> but this is being added in latest migration patches
15:31:13 <ganso> so at some point one will need to be rebased on the other, if it is being handled at all
15:31:23 <bswartz> ganso: migrating snapshots can only be done with driver assistance
15:31:27 <ganso> if it is *to be handled at all
15:31:35 <ganso> bswartz: yes
15:31:41 <bswartz> I don't see how it's related to mountable snapshots
15:32:04 <ganso> if a driver that supports mountable snapshots wants to do a driver-assisted migration
15:32:32 <ganso> the share/API and manager need some code to adjust to that
15:32:36 <bswartz> okay
15:33:11 <bswartz> okay how about migration improvements
15:33:17 <bswartz> 5 more patches here
15:33:22 <bswartz> is it all done?
15:33:31 <ganso> main patch is all done
15:33:39 <ganso> python-manilaclient needs more functional tests
15:34:01 <ganso> manila-ui needs to grey out the options depending on combination, I need to figure out how to do that
15:34:09 <ganso> that's all
15:34:13 <bswartz> okay cool
15:34:42 <bswartz> the stochastic weighing scheduler work is a relatively simple port from cinder but given limited time I'm not going to prioritize it
15:35:05 <tommylikehu_> ok
15:35:17 <bswartz> db-manage-purge looks ready for review
15:35:23 <tommylikehu_> yes,
15:35:44 <tommylikehu_> need more review from you guys
15:35:47 <bswartz> the share type filter on get pools appears merged
15:35:57 <tommylikehu_> right
15:36:11 <bswartz> and the quota usage changes has a merge conflict
15:36:31 <tommylikehu_> I am waiting for the manila's patch to be merged
15:36:36 <bswartz> so overall we have a lot of work done but a lot of reviews to be done
15:37:02 <bswartz> And most of you remember what happens with merge conflicts in the last 2 weeks of any release I'm sure
15:37:10 <bswartz> so we should be trying to get some of these merged asap
15:37:10 <ganso> rebase hell
15:37:22 <bswartz> ganso: +1
15:37:32 <tommylikehu_> +1
15:37:34 <bswartz> okay
15:38:19 <tommylikehu_> https://review.openstack.org/#/c/366614/
15:38:19 <bswartz> okay the design summit leftover topics keep getting pushed back, and now that we're close to feature freeze I think I'll take them off the agenda to save them for PTG, or slightly before PTG
15:38:32 <bswartz> it's not the right time to be bringing up new requirements
15:38:56 <bswartz> so let's jump directly to open discussion
15:39:01 <bswartz> #topic open discussion
15:39:13 <bswartz> I have one topic that came up yesterday
15:39:25 <bswartz> #link https://review.openstack.org/416818
15:39:30 <tommylikehu_> do we have a etherpad for ptg topic?
15:39:44 <bswartz> tommylikehu_: no not yet
15:40:09 <bswartz> we will get the PTG agenda ready soon, as that's coming up fast
15:40:23 <bswartz> but I didn't create an etherpad yet
15:40:24 <tommylikehu_> bswartz: ptg is the best place for your new coming spec
15:40:35 <bswartz> which spec
15:40:49 <tommylikehu_> https://review.openstack.org/416818
15:41:07 <bswartz> that's not a spec
15:41:15 <bswartz> #link https://etherpad.openstack.org/p/manila-pike-ptg-topics
15:41:16 <tommylikehu_> sorry..
15:41:53 <bswartz> back to my topic
15:42:11 <bswartz> akerr discovered that most of our tempest jobs are running very few tests
15:42:30 <bswartz> we have 3 categories of tempest tests: api, api_with_backend, and backend
15:42:48 <bswartz> also scenario
15:43:06 <bswartz> anyways, most of the jobs are running running backend only, and not api_with_backend tests
15:43:14 <bswartz> which I think is wrong, but I wanted to bring it up here
15:43:33 <bswartz> my patch changes things so that those jobs run the api_with_backend tests too
15:43:36 <tbarron> how many tests have we been skipping?
15:43:56 <bswartz> tbarron 85% of them
15:43:58 <tbarron> wow
15:44:12 <bswartz> only for certain drivers though
15:44:25 <bswartz> all of the tests run in the dummy driver job
15:44:57 <bswartz> but LVM was only running like 50 tests out out the 665 tests we have
15:45:03 <bswartz> after my change it runs more like 300
15:45:11 <tbarron> so we should anticipate some fallout work fixing bugs once your change merges ...
15:45:30 <ganso> #link http://docs.openstack.org/developer/manila/devref/tempest_tests.html#running-a-subset-of-tests-based-on-service-involvement
15:45:32 <bswartz> well it's not urgent that my changes merges, and I don't want to make things worse
15:45:51 <tommylikehu_> tbarron: you are right
15:46:13 <bswartz> ganso: thanks for that link I didn't find that yesterday
15:46:34 <bswartz> however I suspect the problem is that we're categorizing tests wrong
15:46:43 <ganso> bswartz: I think it is good to enable api_with_backend on jobs that run fast
15:46:53 <ganso> bswartz: but I disagree on enabling it for generic driver
15:47:22 <ganso> bswartz: can you exemplify a test that is categorized incorrectly?
15:47:23 <tommylikehu_> +1
15:47:23 <bswartz> it's not a question of how fast the tests run, it's a question of whether they increase coverage or not
15:47:31 <tbarron> ganso: ??
15:48:10 <bswartz> we put the tags on the tests because a significant number of tests never touch the backend and therefore there's no value to running them over and over with each different backend
15:48:21 <ganso> bswartz: right
15:48:53 <bswartz> I think a number of tests are tagged api_with_backend that should be tagged backend
15:49:01 <bswartz> I can try to dig up some examples
15:49:15 <ganso> bswartz: in that case your patch is proposing an improper fix
15:49:31 <bswartz> ganso: yes I agree
15:49:51 <bswartz> I didn't know about that devref you linked, and vponomaryov isn't around to clarify this
15:50:10 <tbarron> dumb question: what exactly do the tags mean?
15:51:09 <tommylikehu_> +1
15:51:12 <tbarron> 'api' means api w/o backend involvement?
15:51:14 <bswartz> tbarron: the devref explains that
15:51:19 <tbarron> k
15:51:39 <bswartz> the devref could probably be clearer
15:51:59 <bswartz> but reading it tells me what vponomaryov was thinking when we added these tags
15:52:38 <bswartz> I'm going to -1 my own patch so we don't accidentally merge it
15:53:00 <dustins> Yeesh, those regexes are ugly
15:53:08 <bswartz> dustins: tell me something I don't know
15:53:40 <bswartz> okay thanks for helping me clarify this
15:53:43 * dustins ponders if those could be "hidden" as tox directives
15:54:11 <bswartz> dustins: from what I've read about ostestr (which is a lot, since yesterday) we're doing these regexes exactly right
15:54:29 <bswartz> regexes are inherently ugly
15:54:37 <tommylikehu_> lol
15:54:52 <bswartz> ideally ostestr would implement a better way to filter tests
15:55:39 <dustins> bswartz: Agreed!
15:55:47 <bswartz> okay since someone mentioned the ptg earlier, I'll remind you all that it's in 6 weeks
15:56:07 <bswartz> has anyone found out that they can/can't attend for sure?
15:56:29 <dustins> I'll definitely be there
15:56:37 <tommylikehu_> hope I can make it
15:57:12 <markstur_> still waiting for approval
15:57:34 <bswartz> also I'll start adding topics to the etherpad I just created, and I'll put PTG on the agenda for next week
15:57:37 <xyang1> I'll be there
15:57:39 <tbarron> I don't understand the devref, i.e. I can't tell which tests should be running for various backends by reading it.  I already knew what it tells me when I asked my dumb question.
15:57:47 <ganso> still waiting travel support response
15:57:53 <bswartz> tbarron: doh
15:58:00 <bswartz> tbarron: I'll explain it in the channel
15:58:12 <tbarron> k
15:58:16 <ganso> btw, is it true that it will be only 2 days for manila?
15:58:41 <bswartz> ganso: yes I've only asked for meeting rooms on wednesday and thursday
15:58:59 <bswartz> monday/tuesday will be all cross-project content and those days were not open to us in any case
15:59:04 <ganso> bswartz: this is not really what I expected of a PTG :\
15:59:18 <bswartz> friday we could have used but traditionally 2 full days has been enough for us
15:59:33 <bswartz> ganso: me neither
15:59:38 <tommylikehu_> preparing two days gathering
16:00:15 <bswartz> I'm really surprised by what they're doing with PTG but I'm trying to be open minded about it
16:00:41 <bswartz> I'll save my anger for afterwards, if it turns out badly
16:00:47 <bswartz> okay we're out of time
16:00:48 <bswartz> thanks all
16:00:52 <bswartz> #endmeeting