22:02:37 <kevinbenton> #startmeeting neutron_drivers
22:02:38 <openstack> Meeting started Thu Aug  3 22:02:37 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:42 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:45 <annp> hi
22:02:49 <kevinbenton> amotoki: ping
22:02:56 * armax lurke
22:03:41 <kevinbenton> let's go over the FFE's that were sent to the mailing list
22:04:08 <kevinbenton> #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/120310.html
22:05:38 <kevinbenton> I've looked at the code for this one and I think it's non-invasive enough to merge
22:05:59 <ihrachys> it misses the agent bit that we just discussed in #openstack-neutron though
22:06:06 <ihrachys> I should be able to make it to life tomorrow
22:06:13 <mlavalle> ihrachys mentioned in the patchset he was going to 'look at agent behavior'
22:06:39 <mlavalle> ak, ok that was my answer
22:06:57 <yamamoto> it has no effect for out of tree drivers? (i haven't looked at the patch yet)
22:07:29 <ihrachys> your driver will be notified with NETWORK_UPDATE, and then it's up to you to propagate it
22:07:47 <kevinbenton> the out of tree driver needs to handle the case where the MTU changes
22:08:01 <ihrachys> do we need some conditional to avoid loading the extension if a driver doesn't claim support?
22:08:38 <ihrachys> I thought we don't do that for other features introduced on plugin level
22:08:54 <yamamoto> i have vague concern to add things like it this late as it gives no chance for drivers to adapt.
22:09:23 <kevinbenton> yamamoto: if the driver can't handle the change you could simply have it throw an exception
22:09:59 <ihrachys> kevinbenton, in all honestly, it would still require a patch from their side
22:10:05 <kevinbenton> true
22:10:05 <yamamoto> ok. anyway those kind of concerns can be handled in review, rather than FFE decision
22:10:20 <kevinbenton> but what do drivers do now when the operator changes the MTU configuration and restarts the server?
22:10:38 <ihrachys> I think nothing. we actually don't notify anyone atm.
22:10:52 <kevinbenton> I guess the difference is operator-induced vs regular user API call
22:10:54 <ihrachys> the only way to apply new values is to restart agents
22:11:22 <kevinbenton> ok, well let's figure out if we need an explicit opt-in in the review as yamamoto suggested
22:11:32 <kevinbenton> is everyone okay with granting an FFE otherwise?
22:11:41 <mlavalle> +
22:12:04 <ihrachys> I am biased, no vote :)
22:12:49 <kevinbenton> armax: even though you are lurking, can you give + or - ?
22:12:57 <kevinbenton> for MTU patch from Ihar?
22:13:07 <amotoki> sorry for late
22:13:13 <kevinbenton> amotoki: no problem
22:13:21 <kevinbenton> amotoki: we are just now discussing an FFE for the MTU patch
22:13:26 <kevinbenton> amotoki: http://lists.openstack.org/pipermail/openstack-dev/2017-July/120310.html
22:14:11 <amotoki> I am okay with that one at a quick look
22:14:51 <kevinbenton> ok, i'll assume that one is granted then and reply on the email at the end of the meeting
22:15:10 <ihrachys> thanks folks, I will try to deliver missing bit asap
22:15:19 <kevinbenton> next up is the security group logging one #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/120344.html
22:15:53 <kevinbenton> so there is a fair amount of this left that needs to merge
22:16:12 <kevinbenton> but from what I can tell most of it is isolated and won't interfere unless the service plugin is actually enabeld
22:16:55 <ihrachys> have we landed some pieces of it already?
22:16:56 <kevinbenton> I think the most invasive component is probably the integration into OVSFW
22:16:57 <kevinbenton> https://review.openstack.org/#/c/468281/
22:17:11 <kevinbenton> ihrachys: yeah, I think basic extension definitions landed
22:17:24 <mlavalle> some patchsets are still failing Jenkins. Are these failures due to the patchsets?
22:18:00 <kevinbenton> mlavalle: not sure
22:18:07 <yushiro> annp, you fixed it, did you?
22:18:27 <annp> yes. failed not related
22:18:48 <mlavalle> all of them? there are several pacthes failing
22:19:41 <kevinbenton> annp: is my understanding correct that this is basically the only patch that impacts existing code if the logging plugin is not enabled? https://review.openstack.org/#/c/468281/24
22:19:46 <annp> yes, all of them.
22:19:59 <mlavalle> thanks annp
22:21:25 <annp> kevinbenton, yes. i think
22:21:48 <amotoki> my understanding is same. the existing mechanism driver registers a logging driver
22:21:54 <kevinbenton> yamamoto: you have been reviewing that patch. how risky do you think it is to add this late?
22:23:26 <kevinbenton> My opinion is that even though there is a fair amount left to merge, most of it proposes no risk to the stability of the code except for this one patch
22:23:47 <yamamoto> kevinbenton: i agree
22:24:10 <kevinbenton> So I'm okay with an FFE and to proceed with a best effort to get it merged if that OVSFW patch is not too invasive
22:24:52 <yamamoto> when is the deadline for merging, after an FFE is granted?
22:25:00 <kevinbenton> RC1
22:25:07 <yamamoto> ok
22:25:18 <amotoki> RC1 is next week right?
22:25:29 <kevinbenton> Aug 11th is last day to cut RC-1
22:25:32 <kevinbenton> https://releases.openstack.org/pike/schedule.html
22:25:36 <ihrachys> I am fine with the proposal if it doesn't destabilize gate, f.e. scenario job, even more than it is right now. the number of patches (and their size) makes me pessimistic that we can land it all though.
22:25:40 <mlavalle> next week
22:26:02 <yushiro> kevinbenton, yamamoto Thank you.  We'll do our best.  I understand 11th Aug.
22:26:17 <ihrachys> if you folks believe that you can spin on all those patches and get it all in, then go for it.
22:26:19 <yamamoto> i'm pessimistic too but i see no problem to let it try.
22:26:24 <kevinbenton> yushiro: actually we better target Aug 11
22:26:27 <kevinbenton> aug 10!
22:26:29 <kevinbenton> sorry
22:26:39 <ihrachys> yamamoto, one question is, is there a problem if we land parts only
22:26:42 <yushiro> aha, sorry.  I see  10th.
22:26:43 <kevinbenton> i know the release team doesn't like to release on Friday only
22:26:54 <kevinbenton> so Thursday the 10th would be best
22:26:54 <ihrachys> I guess it's not enabled anywhere unless the driver is on?
22:27:14 <kevinbenton> ihrachys: right, it's my understanding that we would have the service plugin but no drivers that support it
22:27:19 <ihrachys> if we fail to deliver, we can add a releasenote saying it's not ready/experimental
22:27:33 <kevinbenton> ihrachys: +1
22:27:42 <amotoki> +1
22:27:46 <amotoki> we need to test it carefully with this patch but without enabling the feature too.
22:27:53 <mlavalle> +
22:27:58 <amotoki> it looks safe so far though
22:28:29 <kevinbenton> annp: is there a way to arrange the patches so the OVSFW changes can be merged first?
22:28:39 <kevinbenton> so we can get that tested right away?
22:28:52 <kevinbenton> or does it depend too much on the parent patches?
22:29:19 <annp> it depend on parent patches
22:29:27 <kevinbenton> ack
22:29:45 <mlavalle> if rearraging the order is too disruptive, let's keep it this way
22:29:49 <kevinbenton> +1
22:29:59 <kevinbenton> ok, let's grant the FFE and see where we are next thursday
22:30:30 <amotoki> note that we don't have CLI part in pike even if it is merged, right?
22:30:59 <kevinbenton> right, since we're past the client deadline
22:31:13 <kevinbenton> we would have to wait for next client release
22:31:21 <amotoki> yes
22:31:28 <yushiro> amotoki, kevinbenton Oh, OK.
22:31:44 <mlavalle> no need to spend time on that
22:31:44 <kevinbenton> so this will definitely be experimental in that it will require a newer client or direct HTTP API usage
22:32:12 <amotoki> +1 :)
22:32:15 <kevinbenton> ok, next up is networking-midonet
22:32:19 <kevinbenton> #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/120381.html
22:32:32 <kevinbenton> This is just to remove a deprecated plugin
22:32:32 <yushiro> thank you
22:32:50 <yamamoto> i guess it's a pretty safe change.
22:32:51 <kevinbenton> I think it's fine
22:33:14 <kevinbenton> yamamoto: no risk to the Ml2 driver, right?
22:33:17 <kevinbenton> or the l3 plugin
22:33:40 <yamamoto> right
22:34:07 <ihrachys> first, I am glad that midonet reached out. second, I think it's fine and a no-brainer.
22:34:07 <mlavalle> as far as I can see, it's all local to the midonet repo
22:34:15 <kevinbenton> mlavalle: yep
22:34:25 <kevinbenton> ok, this is good to go
22:34:37 <mlavalle> as a wiseman said, it's a no brainer
22:34:42 <amotoki> looks fine
22:34:50 <kevinbenton> next up is dns_domain
22:34:51 <kevinbenton> #link http://lists.openstack.org/pipermail/openstack-dev/2017-August/120430.html
22:35:11 <kevinbenton> i just reviewed the last patch in the series and it looks pretty good
22:35:53 <mlavalle> amotoki saw it last night, what do you think?
22:36:09 <amotoki> it is in good shape
22:36:57 <kevinbenton> ihrachys: any concerns on your end?
22:37:11 <amotoki> mlavalle: is there any func test coverage on this?
22:37:19 <mlavalle> no
22:38:19 <kevinbenton> we don't have any gate jobs that run designate do we?
22:38:27 <mlavalle> no we don't
22:38:39 <amotoki> as far as looking at the code, the existing behavior is kept. we at least need not to break the existing feature
22:38:44 <ihrachys> mlavalle, do they have any in their gate?
22:39:01 <ihrachys> is the existing feature covered fine with tempest api?
22:39:14 <mlavalle> none that test the integration with designate
22:39:28 <ihrachys> I don't see any tempest tests
22:39:40 <mlavalle> we don't have tempest tests
22:39:45 <ihrachys> isn't it a must?..
22:39:49 <kevinbenton> yeah, you need to have a driver loaded to be able to set these attributes
22:39:55 <ihrachys> we add a new api feature; I would expect some tempest tests for that, no?
22:40:05 <kevinbenton> so unless we depend on designate I think we're stuck, is that right mlavalle?
22:40:12 <mlavalle> yes
22:40:19 <ihrachys> oh we can't enable the driver without designate?
22:40:42 <ihrachys> I mean, it's fine if it fails to update it, but just api operations, won't they work?
22:41:03 <kevinbenton> what happens if you enable the designate driver and don't have designate?
22:41:12 <mlavalle> the api operations on ports and floating ips work without designate
22:41:48 <mlavalle> so we can do tempest api tests
22:41:53 <kevinbenton> mlavalle: ok. can you add a parent patch that tests existing API behavior?
22:42:02 <ihrachys> yeah, that would be great, a parent change
22:42:08 <ihrachys> and then the new one extends it to ports
22:42:11 <kevinbenton> that will give us some more confidence that the small refactors required didn't leave something else
22:42:20 <yamamoto> can't we have a non-voting job with designate?
22:42:27 <mlavalle> sure, will do
22:42:50 <kevinbenton> or maybe we can add designate to our scenario job?
22:43:32 <ihrachys> we won't do it in next week
22:43:48 <mlavalle> agree with ihrachys
22:43:48 <kevinbenton> ok, so I think we're okay with an FFE for this one as well then as long as we get some basic API tests to help us ensure some basic sanity
22:44:06 <amotoki> for unit test, can we split new unit test coverage into a parent patch? we can be more confident on the existing driver behavior.
22:44:15 <amotoki> *child patch*
22:44:43 <mlavalle> amotoki: but the unit tests for the previous functionality wasn't touched
22:45:08 <mlavalle> other that re-arranging somo args
22:46:14 <kevinbenton> mlavalle: maybe put the test refactors into a parent patch?
22:46:18 <kevinbenton> amotoki: is that what you mean?
22:46:19 <amotoki> there is some re-arranging. i just want to be conservative
22:46:38 <kevinbenton> that way parent patch is tests pass with existing DNS code
22:47:37 <amotoki> kevinbenton: yes
22:47:54 <kevinbenton> mlavalle: does that make sense?
22:48:05 <mlavalle> kevinbenton: I'll give it a try
22:48:12 <kevinbenton> mlavalle: ok, thanks
22:48:20 <amotoki> mlavalle: thanks
22:48:38 <kevinbenton> Did I miss any other FFEs?
22:48:45 <kevinbenton> I think that was all I saw in the list
22:48:58 <mlavalle> didn't swami send this morning a couple of requests?
22:49:04 <kevinbenton> oh, i missed them
22:49:10 <mlavalle> for dvr
22:49:18 <yamamoto> yushiro: there was no FFE requests from fwaas?
22:49:24 <mlavalle> kevinbenton: let me make sure he sent the emails
22:49:44 <kevinbenton> mlavalle: ctrl-f for Swami doesn't show anything on http://lists.openstack.org/pipermail/openstack-dev/2017-August/thread.html
22:50:11 <yushiro> yamamoto, I have FFE for fwaas v2
22:50:18 <mlavalle> kevinbenton: I just pinged hiom
22:50:56 <kevinbenton> yushiro: do you have a link to an email?
22:51:09 <kevinbenton> yushiro: or do you just want to describe the request here
22:51:13 <mlavalle> kevinbenton: here's one that he wanted a FFE for: https://review.openstack.org/#/c/437986/
22:51:15 <yushiro> kevinbenton, sorry I didn't send e-mail to ML but
22:51:58 <Swami> hi
22:52:31 <yushiro> kevinbenton, it is necessary to merge https://review.openstack.org/#/c/323971/  and their parent patch ( 3 patches)
22:53:08 <yushiro> kevinbenton, In addition, fwaas-dashboard also needs https://review.openstack.org/#/c/475840/
22:53:19 <ihrachys> yushiro, why does it add an 'ocata' alembic script?
22:53:22 <Swami> kevinbenton: Yes I need a FFE for https://review.openstack.org/#/c/437986/
22:54:34 <kevinbenton> ok, DVR one first really quick. I've reviewed https://review.openstack.org/#/c/437986/ a few times already and the new code paths are primarily untouched unless someone is using the new feature
22:54:36 <yushiro> ihrachys, https://review.openstack.org/#/c/425769/  ? oops, this is my mistake.  I'll update it 'pike'
22:55:09 <kevinbenton> haleyb: has been reviewing it as well and I think it should be safe to merge soon
22:55:19 <Swami> kevinbenton: thanks
22:55:54 <kevinbenton> mlavalle, ihrachys, amotoki: if you could review that patch briefly and just reply if you are concerned about merging it on the patch that would be good
22:56:01 <mlavalle> kevinbenton I have also reviewed https://review.openstack.org/#/c/437986/ and think is in good dhape
22:56:21 <kevinbenton> ok, so for FWaaS
22:56:47 <yushiro> yes
22:57:20 <kevinbenton> this https://review.openstack.org/#/c/323971/
22:57:30 <kevinbenton> looks like a new extension so it shouldn't impact the old code, right?
22:58:10 <yushiro> kevinbenton, yes.
22:59:08 <yamamoto> can you remind me the status of fwaas v2?  is it still experimental?
22:59:33 <kevinbenton> +1, it's still considered experimental, right?
23:00:10 <ihrachys> time
23:00:18 <yushiro> maybe yes.
23:00:24 <kevinbenton> ok
23:00:50 <kevinbenton> I think it's fine if the rest of the FWaaS team is okay with it since it looks to be unrelated to old fwaas code
23:01:01 <yamamoto> +1
23:01:01 <kevinbenton> #endmeeting