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