15:00:33 <bswartz> #startmeeting manila
15:00:34 <openstack> Meeting started Thu Jan 18 15:00:33 2018 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <openstack> The meeting name has been set to 'manila'
15:00:38 <amito> o/ hello
15:00:45 <tbarron> hi
15:00:46 <zhongjun> Hi
15:00:48 <bswartz> hello all
15:00:56 <ganso> hello
15:01:10 <bswartz> Here in north carolina we're snowed in
15:01:35 <xyang> hi
15:01:37 <bswartz> Fortunately I still have power and internet
15:01:58 <dustins> \o
15:02:05 <bswartz> I didn't update teh agenda today, but I do want to spend this meeting talking about patches still trying to meet the feature freeze deadline
15:02:43 <bswartz> #topic announcements
15:02:59 <bswartz> We're just 1 week from feature freeze
15:03:36 <bswartz> Typically I aim to push the milestone tags on Monday or Tuesday of the feature freeze week
15:03:57 <vkmc> o/
15:04:26 <toabctl> hi
15:04:41 <bswartz> That gives us about 2 days of buffer to deal with unforeseeable issues such as the upstream infra cloud going out to lunch, or our gate jobs having last minute issues
15:05:24 <bswartz> So please try to have everything workflowed on by Tuesday morning at the latest
15:06:09 <bswartz> Okay
15:06:16 <bswartz> #topic Patches for milestone 3
15:06:50 <bswartz> #link https://review.openstack.org/#/c/530326/
15:06:54 <bswartz> looks like this one is in the gate now
15:08:04 <bswartz> #link https://review.openstack.org/#/c/529142/
15:08:38 <bswartz> ganso: ^ is this going to make it by the milestone?
15:08:40 <ganso> bswartz: I believe that one is not bound to the FF deadline
15:08:54 <bswartz> Well, that seems debatable
15:08:55 <ganso> bswartz: I am not sure, I am debugging connectivity issues
15:09:06 <bswartz> Is it your intention to miss the deadline and to merge it as no-a-feature?
15:09:26 <ganso> bswartz: it is not a feature, it is a patch that improves testing in the gate
15:09:35 <bswartz> I can see the argument both ways, but it's better to have a change like this in by the milestone
15:10:07 <ganso> bswartz: I am almost sure it will not be ready by Tuesday
15:10:09 <bswartz> I haven't reviewed it yet, but I'll take a look
15:10:17 <ganso> bswartz: actually you did :P
15:10:33 <tbarron> Isn't this a test coverage enabler rather than a user visible feature?
15:10:39 <bswartz> ganso: should it have workflow -1 or do you just expect more negative reviews?
15:10:44 <ganso> tbarron: yes
15:11:01 <ganso> bswartz: since it part of another patch, that part may be complete
15:11:09 <ganso> bswartz: I am still debugging the other part that I have to upload
15:11:10 <bswartz> tbarron: yes but the significant extra coverage added by this could affect QA efforts
15:11:20 <bswartz> Okay I see
15:11:26 <ganso> bswartz: it kinda should
15:11:28 <tbarron> ganso: but it would still be good to get it early in case it destabilizes other tests, etc.
15:11:30 <tbarron> bswartz: ack
15:11:34 <bswartz> Let's move on then
15:11:46 <bswartz> #link https://review.openstack.org/#/c/531075/
15:12:22 <bswartz> Anyone from dell/emc here?
15:12:23 <tbarron> They seem to be having CI issues, perhaps independent of the patch, but ....
15:12:48 <bswartz> Indeed, but the patch is in merge conflict now
15:13:06 <bswartz> I hope someone is paying attention to it
15:13:14 <tbarron> It's likely sleep time for the developer right now.
15:13:19 <tbarron> xyang: ^^^^
15:13:21 <bswartz> The patch is in good shape (I reviewed it) and the CI just needs to pass
15:13:28 <tbarron> woops, not any more
15:13:31 <xyang> tbarron: don't ping me any more:)
15:13:36 <bswartz> :-)
15:13:53 <tbarron> xyang: old habit, we'll get you to rouse huawei folks from their sleep instead
15:14:16 <zhongjun> :)
15:14:17 <xyang> tbarron: zhongjun is usually here.  I don't have to worry:)
15:14:23 <tbarron> :)
15:14:27 <bswartz> #link https://review.openstack.org/#/c/530002/
15:14:57 <bswartz> zhongjun: you reviewed this one ^ is it almost ready or are there big problems with it?
15:15:15 <zhongjun> Yes
15:15:39 <zhongjun> It’s not a big problem
15:15:42 <bswartz> Yes it's almost ready?
15:15:44 <bswartz> Okay good
15:16:05 <bswartz> It's a small patch, we just need a second reviewed on that one
15:16:09 <bswartz> #link https://review.openstack.org/#/c/531847/
15:16:16 <zhongjun> But I think it’s still need a few fix
15:16:54 <bswartz> We're missing gouthamr this morning
15:17:03 <bswartz> But I guess there's a few issues here
15:17:12 <amito> morning? :P
15:17:13 <tbarron> looks like his remarks are valid but fixing them shouldn't be a big deal
15:17:17 <bswartz> ganso, erlon: is this going to be sorted out soon?
15:17:26 <tbarron> like say this about manila rather than cinder :)
15:17:37 <bswartz> amito: in the US it's morning -- on the west coast pretty early morning
15:17:49 <amito> yes I got that :)
15:18:34 <erlon> bswartz: I wasnt expecting so many changes, but I can prioritize that
15:18:56 <bswartz> thanks erlon
15:19:02 <tbarron> erlon: I'll review it before the weekend if you address gouthamr's remarks by then
15:20:08 <bswartz> #link https://review.openstack.org/#/c/522685/
15:20:29 <bswartz> This is related to the other filter patch
15:21:13 <bswartz> If we could get a workflow on this, then it will go in as soon as the other filter patch is ready
15:21:46 <bswartz> Am I missing any other patches?
15:22:09 <tbarron> I'll take another look at 522685
15:22:11 <bswartz> It seems like we're actually in good shape to meet feature freeze
15:23:15 <bswartz> Okay let's move onto bugs
15:23:27 <bswartz> #topic Let's Go Over New Bugs
15:23:48 <bswartz> dustins: I'm glad you will have power and internet out in the country
15:23:59 <dustins> bswartz: I didn't for a bit yesterday ;)
15:24:10 <bswartz> #link https://etherpad.openstack.org/p/manila-bug-triage-pad
15:24:31 <dustins> Up first is one we went over a bit ago
15:24:34 <dustins> #link https://bugs.launchpad.net/manila/+bug/1720283
15:24:35 <openstack> Launchpad bug 1720283 in Manila "use openflow to set security group, create port failed" [Undecided,In progress] - Assigned to haobing1 (haobing1)
15:25:12 <tbarron> I suggested we talk about this one again b/c a fix has been proposed
15:25:41 <tbarron> And I'm hoping someone understands the problem and why this fix would be proposed.
15:25:46 <tbarron> It has +1s
15:25:54 <tbarron> So I may be missing something.
15:25:58 <bswartz> How hard is this to reproduce?
15:26:02 <ganso> tbarron: I agree it shouldn't be removing port security
15:26:17 <bswartz> I don't have any experience with openflow -- does it work with the software-only ovs implementation?
15:27:04 <tbarron> Let's say hypothetically that openflow does its own port security so this is a reasonable thing to do if you are using openflow.
15:27:30 <bswartz> Yes but where is the bug?
15:27:31 <tbarron> Doesn't this fix remove port security for everyone else too?
15:28:01 <bswartz> Does the generic driver do something sneaky that's not part of the standard neutron API?
15:28:13 <tbarron> I don't think so.
15:28:40 <bswartz> I'm wondering if the issue here is on the neutron side or on our side
15:28:52 <bswartz> It seems safe to assume that it's on our side, but I'm not sure where
15:29:30 <bswartz> We could be accidentally relying on some undocumented behavior of the specific neutron configuration that we use in our gate
15:29:37 <tbarron> We really need better bug reports.
15:29:54 <bswartz> +1
15:30:02 <bswartz> But a bad bug report is better than no bug report
15:30:07 <bswartz> So I'll take what I can get
15:31:31 <dustins> bswartz: ready for the next one?
15:31:37 <bswartz> Hold on I'm reading the fix
15:31:45 <dustins> sure thing!
15:32:09 <bswartz> It seems like the proposed fix disables port security on the service instance's private port
15:32:44 <bswartz> I'm okay with this -- the service instance's private port is a bit of a hack to begin with
15:33:06 <bswartz> So it doesn't surprise me that it has problems with the security mechanism
15:33:12 <bswartz> It's not like we need any security here
15:33:25 <bswartz> It's the private connection between the m-shr service and the service instance
15:33:59 <bswartz> I'm posting a review
15:34:05 <bswartz> dustins: let's move on
15:34:07 <ganso> bswartz: the generic driver is a hack
15:34:19 <ganso> bswartz: :P
15:34:25 <bswartz> ganso: >_<
15:34:40 <dustins> bswartz: You got it, the rest of these are new bugs with a high "heat" score so let's get started
15:34:45 <dustins> #link https://bugs.launchpad.net/manila/+bug/1699060
15:34:46 <openstack> Launchpad bug 1699060 in OpenStack Heat "Impossible to define policy rule based on domain ID" [Wishlist,Triaged]
15:36:15 <bswartz> It seems a lot of projects have the same bug
15:36:30 <bswartz> And it's not fixed elsewhere that I can see
15:36:35 <dustins> Yeah, likely why these have high heat scores
15:37:00 <dustins> Indeed, just wanted to get some more "modern" discussion around it
15:37:25 <bswartz> It was opened in Pike and not fixed since then
15:37:29 <bswartz> There's a ML thread linked
15:38:12 <bswartz> My stance is that I'm happy to implement a fix that other projects agree to, but it shouldn't be a priority for us to addrses
15:38:36 <dustins> Want to update the bug to reflect that?
15:39:42 <bswartz> I marked it Opinion/Wishlist just like Nova did
15:39:48 <tbarron> I see lbragstad in that bug, seems like the kind of cross-project initiative that he's good at driving
15:40:04 <tbarron> s/in that bug/in that email thread/
15:40:42 <bswartz> Let's move on
15:40:53 <dustins> #link https://bugs.launchpad.net/manila/+bug/1629133
15:40:54 <openstack> Launchpad bug 1629133 in OpenStack DBaaS (Trove) "New neutron subnet pool support breaks multinode testing." [Undecided,In progress]
15:41:35 <dustins> This one's pretty old, but I wanted to bring it up to see if it's still an issue
15:41:55 <bswartz> Well we don't have multinode testing in the gate
15:42:04 <bswartz> Who is doing multinode testing?
15:43:09 <bswartz> Oh I see
15:43:09 <dustins> Good question
15:43:13 <tbarron> not with devstack
15:43:22 <bswartz> This was filed against a bunch of projects, but the bug was ultimately fixed in devstack itself
15:43:32 <bswartz> So the bug is obsolete
15:43:41 <tbarron> I'm confused though, aren't the fixes here central?  in devstack & possibly also neutron
15:43:53 <tbarron> rather than the various other components?
15:43:54 <bswartz> tbarron: that's how it was fixed
15:43:58 <bswartz> #link https://review.openstack.org/#/c/398012/
15:44:13 <bswartz> I'll mark it fix released in manila
15:44:21 <dustins> Sweet
15:45:17 <dustins> #link https://bugs.launchpad.net/manila/+bug/1479303
15:45:20 <openstack> Launchpad bug 1479303 in Manila "Module "manila.share.drivers.zfssa.restclient" is not covered with unit tests at all" [Low,New]
15:46:05 <dustins> Looks like this one is specific to the zfssa driver?
15:46:10 <bswartz> Booo
15:46:13 <tbarron> dustins: Do you have a zfssa (oracle zfs) driver maintainer current?
15:46:29 <dustins> tbarron: I don't, no
15:46:34 * dustins checks sheet
15:46:55 <bswartz> Try Diem Tran <diem.tran@oracle.com>
15:47:14 <bswartz> I don't have a IRC nick for him
15:47:31 <dustins> Yeah, that's who I have, no IRC nick, driver's not in driver log
15:47:45 <bswartz> That driver was added a long time ago
15:48:04 * bswartz looks for running CI
15:48:44 <bswartz> Nope
15:48:48 <bswartz> Looks unmaintained
15:49:35 <bswartz> If oracle comes back with enhancements to the driver, we will have to make them fix their CI and address the unit test covrage issue
15:50:00 <bswartz> And if they don't, then it's buyer beware for this driver
15:50:16 <dustins> Totally
15:51:48 <bswartz> Alright we're starting to run low on time
15:51:53 <bswartz> How many more?
15:52:18 <dustins> bswartz: I've got three more, but if we don't get to them we can always do it next week
15:52:41 <bswartz> Pick the most important one
15:52:57 <bswartz> Then we'll save a few moments for open discussion
15:53:22 <dustins> #link https://bugs.launchpad.net/manila/+bug/1699841
15:53:22 <openstack> Launchpad bug 1699841 in Manila "share-group-type-list don't display share-type" [Undecided,New]
15:53:29 <dustins> This one looks important and quick
15:53:43 <dustins> Looks like an enhancement
15:54:36 <bswartz> It's not clear if the API is also missing this information
15:54:45 <bswartz> If so, then yes it's an enhanvement
15:54:51 <bswartz> If it's just a client issue, then it's a bug
15:55:37 <tbarron> maybe follow up to yogesh on his remark: 'resort to using API, no avail'
15:55:52 <bswartz> I'm looking at the code
15:55:56 <tbarron> cheater
15:56:06 <bswartz> I see a show method on the controller for ShareGroupTypesController
15:56:46 <bswartz> The problem may be down in the DB layer though
15:57:12 <bswartz> Someone just needs to setup a group type, and poke the API with curl to see what it says
15:57:38 <bswartz> This bug deserves a followup for sure though
15:57:43 <xyang> share type is actually in the code
15:57:51 <bswartz> Okay in the last 2 minutes...
15:57:55 <bswartz> #topic open discussion
15:58:02 <bswartz> Anyone have any last minute topics?
15:58:04 <xyang> https://github.com/openstack/manila/blob/master/manila/api/views/share_group_types.py#L27
15:58:18 <bswartz> amito: I saw your question in the channel
15:58:23 <lbragstad> o/
15:58:40 <lbragstad> i saw a ping about https://bugs.launchpad.net/manila/+bug/1699060 and i agree with the assessment
15:58:41 <openstack> Launchpad bug 1699060 in OpenStack Heat "Impossible to define policy rule based on domain ID" [Wishlist,Triaged]
15:58:47 <bswartz> Manila's meetings are indeed split with a 2 day gap and we did that to avoid conflicts with cinder
15:58:58 <tbarron> lbragstad: thanks
15:59:06 <bswartz> lbragstad: tu
15:59:08 <bswartz> ty
15:59:11 <lbragstad> just wanted to plug that we'll be looking to have some cross project discussions related to those topics if anyone is interested in participating, we'd love the input!
15:59:38 <bswartz> amito: I realize it causes problems for anyone who wanted to only attend only the manila portion of the PTG
15:59:57 <tbarron> amito does cinder too I think
16:00:02 <xyang> bswartz: Is it Tuesday and Friday?
16:00:02 <bswartz> But our working assumption is that most people interested in Manila are also interested in Cinder
16:00:29 <bswartz> And we didn't want to meet on Monday, because the most important crossproject topics typically get covered on Monday
16:00:38 <bswartz> So it's Tuesday+Friday
16:01:00 <bswartz> And we're out of time
16:01:02 <bswartz> thanks all
16:01:03 <tbarron> xyang: https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true
16:01:15 <bswartz> #endmeeting