15:01:36 <bswartz> #startmeeting manila
15:01:38 <openstack> Meeting started Thu Aug 31 15:01:36 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:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:41 <openstack> The meeting name has been set to 'manila'
15:01:47 <bswartz> hello all
15:01:48 <cknight> Hi
15:01:49 <ganso> hello
15:01:49 <raissa> hi
15:01:49 <toabctl> hey
15:01:51 <jprovazn> hi
15:01:52 <dustins> \o
15:01:55 <zhongjun> hi
15:01:57 <xyang1> Hi
15:01:59 <chandankumar> \o/
15:02:01 <amito-infinidat> .o/
15:02:03 <jungleboyj> @!
15:02:04 <_pewp_> jungleboyj (ه’́⌣’̀ه )／
15:02:30 <tbarron> hi
15:02:31 <bswartz> tbarron gouthamr vponomaryov markstur: courtesy ping
15:02:37 <gouthamr> hi o/
15:02:51 <bswartz> #topic announcements
15:03:00 <markstur> hi
15:03:09 <bswartz> On Tuesday the official Pike release went out!
15:03:25 * bswartz claps
15:03:26 <jungleboyj> Yay!
15:03:34 <markstur> woot
15:03:41 <bswartz> for Manila the final release was identical to RC1
15:04:13 <bswartz> now master is completely open for Queens work, and the stable/pike branch is open to bugfix backports
15:04:42 <bswartz> also ocata is closed to non-critical bugfixes
15:04:56 <bswartz> but we have driverfixes/ocata for those
15:05:30 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:05:45 <bswartz> #topic share groups docs
15:06:11 <bswartz> so we managed to get share groups wrapped up in pike, but the docs didn't catch up
15:06:37 <bswartz> The CLI ref is accurate, thanks to it being automatically generated
15:06:48 <zhongjun> #link https://review.openstack.org/#/c/490716/    Added API doc for share group
15:07:09 <bswartz> but the API ref is badly inaccurate, and the admin guide also doesn't mention things admins need to know about group types and group extra specs
15:07:11 <tbarron> btw we don't have driverfixes/ocata yet
15:07:22 <bswartz> tbarron: doh!
15:07:30 * bswartz assumed and was wrong
15:07:42 <bswartz> now would be a good time to create driverfixes/ocata
15:08:10 <bswartz> if someone would like to volunteer to do that
15:08:20 <gouthamr> not until ocata has moved into phase-2 support, correct?
15:08:28 <gouthamr> (or phase 3?)
15:08:36 <bswartz> gouthamr: I believe that is now
15:08:55 <bswartz> is there an alternative schedule I'm not aware of?
15:09:07 <gouthamr> okay.. i thought there's an official email
15:09:10 <bswartz> btw sorry for getting offtopic
15:09:18 <bswartz> zhongjun: thanks for that docs patch
15:09:43 <jungleboyj> Cinder is going to make driverfixes/ocata today.
15:09:57 <bswartz> we need to merge that, and also remove all the consistency groups API docs
15:10:04 <zhongjun> bswartz: you are welcome
15:10:08 <bswartz> and we need some additions to the admin guide
15:10:23 <bswartz> I'm wondering if people are aware of other docs that needs updating for share groups
15:10:57 <bswartz> I've been looking and I haven't found any other docs that need share groups info
15:11:02 <zhongjun> bswartz: Why we need to remove all the consistency groups API docs, we could add some notes?
15:11:19 <bswartz> zhongjun: those APIs are gone since Ocata
15:12:02 <zhongjun> bswartz: but it still exist in some version, like mitaka
15:12:24 <zhongjun> s/version/versions
15:12:32 <bswartz> I don't have a problem if the documentation exists in old docs, but really nobody should be using that feature since it's been killed
15:12:59 <bswartz> this is the point of an experimental feature -- it can get removed so nobody should depend on it
15:13:59 <bswartz> zhongjun: are you willing to do the other docs patches needed to get the api-ref in shape?
15:14:16 <bswartz> and are there any volunteers to update the admin guide with share-group-types?
15:15:05 <bswartz> I'm more concerned with removing inaccurate information than with filling in omissions, but those things should be done relatively soon
15:15:06 <zhongjun> bswartz: If there isn't any volunteers to update the other docs, I would like to do
15:15:22 <bswartz> zhongjun: thank you
15:15:29 <tbarron> zhongjun++
15:15:41 <bswartz> I was hoping vponomaryov would be around as a resources to help with this but he's been offline recently
15:16:21 <bswartz> okay moving on...
15:16:27 <bswartz> #topic Move manila_tempest_tests to a new repo
15:16:27 <zhongjun> bswartz: yeah, I could send email to him, I hope I can get response
15:16:35 <bswartz> raissa: you're up
15:16:47 <raissa> hi
15:16:54 <raissa> so we've been talking about this goal https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
15:16:55 <chandankumar> raissa: bswartz Hello
15:17:10 <raissa> and we think it may be time to start doing that for manila
15:17:13 <chandankumar> I am volunteering for tempest plugin split for Queens Goal
15:17:32 <bswartz> so this was discussed at Atlanta PTG
15:17:40 <tbarron> chandankumar: hi!!
15:17:48 <bswartz> the goal didn't get picked up for Pike, but it seems it did for Queens
15:17:55 <gouthamr> chandankumar: nice. welcome!
15:17:56 <chandankumar> tbarron: hello.
15:18:05 <bswartz> I understand why we need another repo for building the manila tempest plugin
15:18:14 <chandankumar> bswartz: the goal is for Queens, it is just a heads up,
15:18:25 <bswartz> I've expressed an opposition to actually moving the test in the past
15:18:47 <bswartz> I think it's possible to create a new repo that depends on manila and pulls the tests in from manila
15:19:24 <bswartz> my thinking is that having tests and code in different repos makes certain types of changes unnecessarily complex
15:20:01 <bswartz> so I would like to make sure we fully investigate the possibility of creating a shell report for manila-tempest that simply depends on the tests in the manila tree
15:20:05 <tosky> if I can... hi all; my experience from Sahara shows that having high-level tests in a separate repository makes thing less complicated
15:20:13 <tosky> we are not talking about unit tests
15:20:21 <chandankumar> bswartz: but seperating the tempest plugin to a seperate repo makes debugging, dependencies and maintaince much easier
15:20:27 <zhongjun> chandankumar: welcome
15:20:37 <tosky> whast you describe is exactly not fulfilling the upstream goal
15:20:56 <chandankumar> bswartz: we will be move this part https://github.com/openstack/manila/tree/master/manila_tempest_tests to a seperate repo
15:20:59 <tosky> which type of changes do you think would be more complicated?
15:21:12 <bswartz> I agree there are benefits to the split approach, but the downsides are always ignored over when I bring them up
15:21:24 <tosky> that's why I'm asking which ones
15:21:37 <tosky> we didn't notice relevant downside in 2 years
15:21:46 <bswartz> tosky: I don't suppose you were part of the discussion at the Atlanta PTG? We hashed this out at lengh
15:21:58 <tosky> I wasn't there, no, unfortunately
15:22:06 <bswartz> we can reprise the discussion, but it's not a short one
15:22:10 <ganso> tosky: can you highlight what the most pratical differences were?
15:22:38 <tosky> we manage the sahara tempest plugin as branchless, roughly following tempest cycle
15:22:55 <tosky> we don't need to backport changes to the tests, which are targeted to a specific API and valid for all versions
15:23:16 <bswartz> in the past there have been multiple occasions where we had to fix bugs in the manila code where the test was actually validating incorrect behavior
15:23:18 <tosky> in the rare case of a different behavioral change, some tests can be enabled/disabled through config options
15:23:36 <tosky> which are set by devstack plugin
15:23:38 <chandankumar> bswartz: one example is https://bugs.launchpad.net/manila/+bug/1713822
15:23:40 <openstack> Launchpad bug 1713822 in tempest "manila tempest plugin as tagged (16.1) uses features from tempest beyond 16.1.0 (pike upper constraint)" [Undecided,Invalid]
15:23:54 <bswartz> so the code was wrong and the test was wrong and it wasn't possible to fix the code without fixing the test and vice versa
15:24:14 <bswartz> when the code and tests are in the same repo, it's a simple change to address these kinds of issues
15:24:30 <bswartz> when they're in separate repos, at least 3 changes are required to resolve that kind of problem
15:24:51 <tosky> how many times does this happen?
15:25:11 <ganso> bswartz: in a separate branchless repo that would be solved by fixing the test according to the correct behavior and dropping the validation of the incorrect one altogether
15:25:13 <raissa> yeah, it shouldn't happen a lot
15:25:17 <bswartz> also, separation of tests from code makes it impossible to add new features and test coverage for those features at the same time
15:25:43 <bswartz> ganso: yes, but that's a 3 step process
15:25:46 <tbarron> today's scheme has issues b/c tempest is branchless (relies on tags only) and manila tempest plugin branches; syncing the two in distros is challenging
15:26:04 <ganso> bswartz: they would still need a "depends-on", pretty much what we already do today if the patches are separate for easier reviewing
15:26:09 <tosky> not at the same time, but I don't see why it is so challenging
15:26:13 <tbarron> but if we separate we should make a recipe for the three-steps when it's required
15:26:27 <tosky> exactly, depends-on allows you to test properly
15:26:49 <bswartz> tosky: it encourages a culture where tests are written after the code instead of vice versa
15:27:10 <tosky> bswartz: no, it's up to you, as core, to not approve the patch
15:27:23 * tbarron notes bswartz advocating that faddy TDD stuff :)
15:27:35 <bswartz> I want to be able to block feature code from merging until tests are complete
15:27:41 <bswartz> tbarron: please no TDD
15:27:42 <tosky> and you can
15:27:47 * tbarron is just messing with bswartz
15:27:48 <tosky> -2 is still valid
15:28:26 <tosky> you -2 the feature until it has a test, it's not different than what's happening now
15:28:46 <tbarron> we do that for unit tests all the time in review
15:28:52 <tbarron> usually just -1 but still
15:28:55 <bswartz> fundamentally I'm opposed to the proliferation of repositories which has become the norm in OpenStack, and this is one more example of it
15:29:18 <bswartz> I suspect I'm the only one who feels this way though
15:29:27 <tbarron> bswartz: is your opposition to this strong enough that you want manila to be a special snowflake?
15:30:01 <tbarron> i see some arguments both ways but think it's important to either work with the overall community direction or to change it
15:30:15 <ganso> I don't see major disadvantages
15:30:26 <raissa> tbarron: +1
15:30:35 <bswartz> tbarron: no I choose my battles and this one doesn't seem winnable
15:30:53 <bswartz> git.openstack.org has 1814 git repos on it by my count
15:31:35 <bswartz> and I don't want to stand in the way of progress
15:31:46 <gouthamr> +1 = 1815
15:31:51 <bswartz> ...
15:32:33 <bswartz> anyways I'm glad we have volunteers to help us make these changes
15:32:48 <bswartz> thank you chandankumar, thank you raissa
15:32:56 <chandankumar> i would love to help
15:33:11 <raissa> bswartz: thank you
15:33:16 <bswartz> my request is that you also help work through some of the other issues that may result from this change -- like how we deal with pike and earlier branches
15:33:25 <chandankumar> If you are going to PTG, andreaf will be doing a session on tempest plugin split walkthrough
15:33:30 <chandankumar> donot forgot to attend that
15:33:42 <chandankumar> https://etherpad.openstack.org/p/qa-queens-ptg
15:34:01 <bswartz> I'll be at Denver but only a cross project capacity since we're doing the Manila PTG virtually
15:35:11 <bswartz> anything else we need to discuss on this topic?
15:35:18 <chandankumar> bswartz: i will work raissa to get it done in order to complete this goal
15:35:29 <raissa> I think that's all for now
15:36:03 <bswartz> I should also point out that this is only now possible thanks to the work done on tempest-lib to get us to the point where Manila didn't need to pin ourselves to a specific tempest commit
15:36:29 <bswartz> having a stable tempest-lib is a huge step forward
15:36:36 <tbarron> +1000
15:37:00 <bswartz> in the bad old days we had to do all kinds of ugly things to keep our tests from failing
15:37:03 <chandankumar> yup
15:37:44 <bswartz> much of my concerns about tempest problems come from that time and some rather bad memories
15:37:47 <raissa> yes, that's why I thought it was time to bring it up
15:38:21 <bswartz> but now things are better so I'm optimistic that we can achieve the goal without inflicting a bunch of pain on ourselves
15:38:33 <bswartz> #topic open discussion
15:38:40 <bswartz> are there any other topics for today?
15:40:39 <bswartz> okay we'll meet as normal next week, and we'll have to figure out what to do about the following week (Denver)
15:40:58 <bswartz> Manila virtual PTG is 3 weeks from yesterday
15:41:26 <bswartz> I haven't posted deadlines for things like queens specs but expect them to be similar to the pike deadlines
15:42:02 <bswartz> thanks everyone
15:42:14 <bswartz> #endmeeting