15:00:38 <bswartz> #startmeeting manila
15:00:39 <openstack> Meeting started Thu Mar  9 15:00:38 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:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:43 <openstack> The meeting name has been set to 'manila'
15:00:46 <cknight> Hi
15:00:49 <xyang2> hi
15:00:50 <vponomaryov> Hello
15:00:52 <jprovazn> hi
15:00:53 <ganso> hello
15:00:55 <Yogi1> Hello
15:01:11 <tbarron> hi
15:01:27 <gouthamr> hi
15:01:37 <bswartz> markstur toabctl: courtesy ping
15:01:47 <toabctl> hi
15:01:49 <bswartz> hello all
15:01:56 * toabctl is in another meeting in parallel.
15:01:57 <bswartz> #topic announcements
15:02:12 <bswartz> I don't have any announcements for today but ganso does
15:02:16 <markstur> hello
15:02:18 <ganso> bswartz: thanks Ben
15:02:24 <ganso> So, I have two very unfortunate announcements to make:
15:02:38 <ganso> 1) I've been assigned the task by a Hitachi representative to deliver a message to the manila community, in which Hitachi has been involved.
15:02:51 <ganso> The message is that unfortunately Hitachi will be discontinuing community participation and will only operate through Hitachi software distribution channels.
15:03:11 <vponomaryov> since when?
15:03:14 <bswartz> :-(
15:03:18 <dustins> :(
15:03:19 <ganso> vponomaryov: since as right now
15:03:21 <toabctl> bad news...
15:03:26 <ganso> 2) Regarding myself as a community member: As some of you know, I was working as a third party for Hitachi, and as of right now I am unfortunately no longer being sponsored to work with the community.
15:03:47 <ganso> I am going to try to stay involved and engaged as long as my free time allows, but in the current situation, I am positive that the amount of involvement will not be enough to work on specs, features, or perform many code reviews.
15:04:02 <tbarron> :(
15:04:20 <ganso> so, yea, :(
15:04:30 <bswartz> I'm sorry to hear that ganso, your contributions will be missed
15:04:44 <tbarron> this stinks
15:04:59 <vkmc> o/
15:05:07 <gouthamr> ganso: sorry to hear that... i really hope someone can sponsor your work
15:05:27 <bswartz> it's normal for companies to join/leave open source communities as their business priorities dictate
15:05:42 <cknight> ganso: who will own Hitachi CI?  Does Hitachi not want in-tree drivers?
15:05:49 <bswartz> hopefully some other company with an interest in the future of manila would be interested in sponsoring ganso's continued work
15:06:22 <ganso> cknight: as of this moment, the CI is located in my team's site, and will be shut down
15:06:41 <ganso> cknight: from the message, I presume it will not be maintained anymore
15:06:54 <tbarron> ganso: is this just a hitachi/manila thing, or more general?
15:06:54 <bswartz> cknight: we don't kick drivers out of tree anymore -- our current threat is to mark the driver as unmaintained if the maintainer stops working in it
15:07:03 <toabctl> ganso, so the driver needs to be removed?
15:07:05 <ganso> cknight: regarding removal of drivers from the upstream code, I have not been informed of any action w.r.t that
15:07:16 <ganso> tbarron: manila and cinder
15:07:21 <ganso> tbarron: probably kolla as well
15:07:29 <tbarron> double or triple :(
15:07:36 <cknight> ganso: understood.  not good news.
15:08:21 <bswartz> yeah this is sad
15:08:47 <bswartz> We need to keep encouraging more sponsorship of the project though
15:09:06 <ganso> my personal wish is that I could continue working with OpenStack, and more specifically manila
15:09:13 <bswartz> okay let's move on to our busy agenda
15:09:19 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:09:28 <bswartz> #topic Specs Deadline (continued)
15:09:39 <bswartz> so we ran out of time on this topic last week
15:10:30 <bswartz> as I said I would do, I posted the tentative deadline for ALL specs as the Pike-1 milestone on the official schedule
15:10:47 <bswartz> we could choose to relax those deadlines, but I'd prefer not to
15:11:16 <bswartz> that dead as it stands is 5 weeks away
15:11:34 <jungleboyj> o/ Sorry for being late.
15:11:34 <bswartz> and I don't want to wait more than 5 weeks to make decisions about what's in and what's out of pike
15:11:47 <cknight> bswartz: +1
15:11:49 <bswartz> s/dead/deadline/
15:12:17 <bswartz> if there are special circumstances for individual specs we could make exceptions
15:12:55 <bswartz> but it would be best for everyone if we just got on the with the process of reviewing specs and making the decisions so we can shift to focus on code
15:13:17 <bswartz> anyone unhappy with this plan?
15:13:31 <bswartz> I said last week we could put this to a vote if there's still disagreement
15:13:45 <vponomaryov> would be fair
15:13:52 <bswartz> #link https://releases.openstack.org/pike/schedule.html
15:14:21 <bswartz> okay sounds like we're agreed
15:14:37 <bswartz> #topic Community Goals
15:14:43 <bswartz> #link https://github.com/openstack/governance/blob/master/goals/pike/deploy-api-in-wsgi.rst
15:14:49 <bswartz> #link https://github.com/openstack/governance/blob/master/goals/pike/python35.rst
15:15:10 <bswartz> there are 2 TC-approved goals for Pike
15:15:22 <bswartz> we must respond to these one way or another
15:16:11 <bswartz> the py35 looks very easy to achieve, for us
15:16:25 <bswartz> we'd just need to add a py35 gate job for manila-ui
15:17:20 <bswartz> the wsgi goal will require a bit more effort, but I expect that it won't be terrible
15:17:42 <bswartz> I'm looking for a volunteer that's interested to test manila with a proper wsgi container
15:18:06 <bswartz> the process should be quite similar to whatever works for cinder because at the time we forked cinder it was wsgi-enabled
15:18:42 <tbarron> there's a cinder patch to devstack/lib/cinder up for this, but we are a plugin ...
15:18:53 <jungleboyj> bswartz:  And Sean thought that would be pretty easy for Cinder to get done.
15:19:18 <bswartz> yeah I don't expect it to be a ton of effort, but it's something that we're required to do so I want to bring it up early
15:19:19 <vponomaryov> tbarron: what is wrong with being plugin?
15:19:37 <tbarron> vponomaryov: nothing wrong, I just didn't see the same toggle at first glance
15:19:41 <jungleboyj> bswartz: +1
15:20:08 <bswartz> I personally haven't played with wsgi stuff before but this was discussed somewhat extensively at PTG and it sounded like it should be easy to do
15:21:00 <bswartz> well maybe we can do what we usually do and wait for cinder to solve it then steal their good work
15:21:05 <bswartz> :-)
15:21:10 <tbarron> bswartz: +1
15:21:45 * jungleboyj wonders if I want to join these meetings. ;-)
15:21:46 <bswartz> if anyone wants to volunteer to own that please contact me
15:21:55 <bswartz> let's move on though
15:22:06 <bswartz> #topic Experimental APIs
15:22:29 <bswartz> so this topic was also discussed last week at some length
15:23:05 <bswartz> #link http://eavesdrop.openstack.org/meetings/manila/2017/manila.2017-03-02-15.00.log.html
15:24:07 <bswartz> so the current plan is to address our current bugs so that experimental stuff doesn't leak through to the nonexperimental APIs
15:24:53 <bswartz> and then to reconsider if a different form of namespacing experimental APIs from stable APIs would be better than what we have now
15:25:11 <bswartz> currently we use HTTP headers to namespace them
15:25:20 <bswartz> there's a proposal to use a different REST endpoint
15:25:47 <bswartz> IMO the differences between the 2 are cosmetic only and not worth pushing a major change, but I'm open to hearing why Im' wrong
15:26:14 <bswartz> lastly we did not get to the question of whether we want to allow more experimental features to merge in pike
15:26:21 <cknight> bswartz: +1, mostly cosmetic.  2 sides of the same coin.
15:26:34 <tbarron> do we have any new experimental APIs in the pipeline for pike?
15:26:34 <bswartz> some were in favor of a blanket ban on new experimental stuff
15:26:45 <bswartz> tbarron: we won't know until 5 weeks from now ;-)
15:26:46 <ganso> bswartz: someone replied to your ML PTG summary message, saying that the endpoint approach  is likely to be a thing other project will be onboard
15:26:51 <cknight> bswartz: I did it with headers because it was a trivial (and elegant, IMO) extension of microversions
15:27:21 <bswartz> ganso: yes I saw that -- I should reply
15:27:25 <tbarron> my thought is that this decision may not be urgent.
15:27:36 <vponomaryov> agree
15:27:44 <vponomaryov> need to wait until we finish with specs
15:27:52 <bswartz> tbarron: we can make the decision on a case by case basis -- we just need to agree NOT to impose a blanket ban on experimental stuff
15:28:23 <cknight> I think it's more important to get the current experimental features out of that status.  Experimental is not a stable state, and we know it is a deterrent for some.
15:28:23 <bswartz> for individual specs we can make a call about whether the change should be experimental or not
15:29:07 <bswartz> gouthamr: you were the loudest voice for never doing another experimental feature
15:29:14 <tbarron> well, I wasn't proposing that myself, even though I do think the costs for core features need to be weighed in when we decide - amount of thrash, liklihood of false negatives in gate, etc.
15:29:59 <bswartz> oh looks like gouthamr wandered AFK
15:30:06 <gouthamr> bswartz: i respectfully disagree with the notion here about doing things this way.. but i will continue to work in fixing our bugs
15:30:11 <bswartz> alright then we're agreed
15:30:35 <bswartz> #agreed team will make calls about experimental APIs on a spec-by-spec basis for new features in pike
15:30:56 <bswartz> oops
15:30:58 <bswartz> #undo
15:30:59 <openstack> Removing item from minutes: #agreed team will make calls about experimental APIs on a spec-by-spec basis for new features in pike
15:31:49 <xyang1> I thought gouthamr was in favor of using a different endpoint
15:32:24 <bswartz> gouthamr: so there are 3 issues -- the first one (fixing bugs) is settled, the second one (the decisions about the mechanism) is being deferred intentionally, but we need to make a call about how to handle new APIs proposed in pike
15:32:32 <gouthamr> xyang1: i still am :) but we discussed it at length in the last meeting..
15:32:42 <bswartz> xyang1: yes and we're not talking about that topic now
15:33:02 <bswartz> to use a strawman, let's say we plan to do share backup this cycle
15:33:21 <bswartz> it would involve several new APIs which we may or may not want to commit to
15:34:09 <bswartz> I think that we should reserve the option of merging the feature with an experimental API instead of keeping the feature out of tree until Queens, assuming all of our other criteria are met
15:34:39 <cknight> bswartz: I would prefer to see those as experimental for at least 1 cycle, but I would also prefer to prioritize getting current APIs out of experimental status first.
15:35:01 <cknight> bswartz: Otherwise it looks like we can't ever finish anything.
15:35:07 <bswartz> it doesn't mean new features have to be done that way -- if the APIs are proposed and they seem perfect then we could merge it as stable -- that just hasn't happened for any new big things in the past
15:35:44 <bswartz> gouthamr: can you get on board with that plan?
15:35:57 <gouthamr> bswartz: +1
15:36:04 <bswartz> okay
15:36:09 <bswartz> #agreed team will make calls about experimental APIs on a spec-by-spec basis for new features in pike
15:36:22 <gouthamr> bswartz: and we evolve them as necessary with microversions, as intended.
15:36:26 <bswartz> #topic Refactor of Tempest scenario base classes
15:36:35 <bswartz> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/113071.html
15:36:59 <bswartz> I saw this thread and wanted to bring it up here briefly
15:37:09 <bswartz> since scenario tests are important to me
15:37:23 <bswartz> I'm not actually sure what the impact of this is on manila
15:37:38 <bswartz> has anyone else looked at this?
15:37:44 <gouthamr> bswartz: https://review.openstack.org/#/c/442719/
15:37:54 <vponomaryov> bswartz: we will need to refactor our code on next tempest version bump
15:38:20 <dustins_> bswartz: I've looked at it a little bit, yes
15:38:46 <bswartz> wow why the new 1200 line file?
15:38:55 <bswartz> this can't be imported from somewhere?
15:39:00 <dustins> Specifically, I've been looking at the Waiters and Execptions classes
15:39:26 <dustins> And I don't know
15:39:29 <gouthamr> bswartz: they're going to make changes to that class in particular
15:39:40 <tbarron> bswartz: I *think* it's a temporary move, to get out of the direct tempest import
15:39:43 <bswartz> oh so we're getting a temporary copy
15:39:47 <bswartz> right
15:39:57 <dustins> I'm still figuring out the Tempest internals myself, unfortunately
15:40:10 <dustins> It's a bit of a mess, if I'm honest
15:40:13 <bswartz> okay well we want to stay on top of that change
15:40:41 <vponomaryov> bswartz: it is first step before making manila tempest tests separate project )
15:40:41 <bswartz> as vponomaryov says, we'll probably be forced to resolve some issues when we next bump the tempest commit cash
15:40:48 <bswartz> gah!
15:40:56 <gouthamr> vponomaryov: hahaha
15:41:15 <bswartz> this community is too repo-happy
15:41:28 <dustins> Heh
15:41:29 <bswartz> maybe it's just a pythonic thing to do and I should stop worrying about it
15:41:40 <gouthamr> pbric
15:42:08 <bswartz> but the list of repos here is horrifyingly long: http://git.openstack.org/cgit
15:42:29 <bswartz> IDK how anyone can fit all those repos into their brain
15:42:42 <vponomaryov> bswartz: my browser is not crashing opening this page, then it is ok ))
15:42:43 <tbarron> just the ones your brain requires
15:42:53 <dustins> To be fair, it looks like a good amount of them are all deb-<NAME OF PACKAGE>
15:42:56 <tbarron> or that your brain tests require
15:43:00 <gouthamr> vponomaryov: internet explorer? me too!
15:43:07 <bswartz> tbarron: but *somebody* has to worry about all of them -- people that build distros for example
15:43:22 * tbarron ducks
15:43:29 <bswartz> oh wel
15:43:37 <bswartz> we're off topic now
15:44:00 <bswartz> I guess there's nothing else to say about this topic, we just need to review and merge that patch I suppose
15:44:22 <bswartz> #topic open discussion
15:44:28 <tbarron> bswartz: andrea is pretty busy, should we just fix the pep8 issues for him?
15:44:33 <bswartz> anyone have anything else for today?
15:44:36 <bswartz> tbarron: yes
15:44:40 <tbarron> bswartz: kk
15:45:00 <dustins> tbarron, bswartz: I can have a look at the patch and see what needs doing on it
15:45:07 <bswartz> oh
15:45:12 <bswartz> the forum
15:45:18 <tbarron> dustins: just cherry-pick it and run pep8
15:45:21 <bswartz> some of you may have seen ttx's announcement about boston
15:45:28 <tbarron> dustins: fix and git-review
15:45:39 <dustins> tbarron: indeed, should be easy to fix!
15:45:41 <jprovazn> I've updated the user messages spec and related patches (https://review.openstack.org/#/c/434277/) - so if you have a momment, please take a look
15:45:42 <vponomaryov> bswartz: no manila in Boston?
15:45:46 <bswartz> I wanted to make it clear that we have no plans to do any manila specific sessions in boston
15:45:47 <markstur> Fenway Park!
15:45:59 <bswartz> developers are still welcome to go and participate
15:46:20 <bswartz> and it sounds from ttx's mail like it's *strongly encouraged*
15:46:48 <bswartz> however I think it's unreasonable to expect developers to travel 4 times a year for a project like manila
15:47:09 <bswartz> we should find a way to do all of our face-to-face work either at the conferences or the PTGs, but not both
15:47:16 <vponomaryov> especially if ther eis no free swag for each attendee ))
15:47:19 <markstur> the email shouted that developers should attend
15:47:24 <dustins> Yeah, I think it'll be a fools errand to try to convince my manager to go to the Summit
15:47:32 <dustins> We'll see about a second PTG as well :)
15:47:37 <bswartz> since we did the PTG for Pike, I plan to skip the Conference/Forum
15:47:48 <bswartz> for Queens we could decide to do things differently
15:48:32 <bswartz> I will be in boston briefly at least to do PTL-ish things, but I won't attend all 4 days of the forum
15:48:56 <xyang1> bswartz: skipping Sydney?
15:49:09 <bswartz> xyang1: that's TBD
15:49:36 <vponomaryov> xyang1: I wonder who chose Syndey, it will be very expensive for majority of attendees
15:49:37 <bswartz> honestly we need to see what the plans are for a Queens PTG and if there's any improvement from Pike
15:50:02 <bswartz> and yes I don't relish the idea of spending a ton of money and time flying to australia
15:50:43 <bswartz> anyways -- all of that is TBD
15:51:04 <bswartz> Boston is the next event and I wanted to make sure nobody was expecting a bunch of manila-specific sessions there
15:52:05 <bswartz> one option we have as a community is to go back to meeting at the conferences and to skip PTGs
15:52:36 <bswartz> there will be space for developers to meet and work at the conference (in theory) and we could do virtual PTGs a different week than the actual PTG
15:52:51 <bswartz> that's just a possibility -- something to decide this summer
15:52:57 <bswartz> I think that's it for today
15:53:13 <bswartz> thanks all
15:53:22 <bswartz> #endmeeting