15:05:54 #startmeeting bgpvpn 15:05:55 Meeting started Tue Sep 26 15:05:54 2017 UTC and is due to finish in 60 minutes. The chair is tmorin1. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:58 hi everyone 15:05:59 The meeting name has been set to 'bgpvpn' 15:06:06 I'm not sure who is around 15:06:16 pcarver ? doude ? 15:06:29 hi 15:06:41 I was going to propose a very short meeting because I'm in a face2face meeting right now 15:06:43 hi doude 15:07:27 doude: on the route-control first implementation change (https://review.openstack.org/#/c/481125/) 15:07:35 I've seen your comments (thanks!) 15:07:52 I'll address them soon (this week I hope) 15:08:05 the comments on class inheritance seem reasonable 15:08:33 I think I also agree with you that the check for port_association operation are not needed 15:08:53 ok I just think it but not tried, need to be validated 15:08:55 the other comment abour _validate_port : I don't know, but I'll have a look 15:09:05 hi, sorry, I'm hear but still on a voice conf call that's running long. 15:10:57 I think you should also validate port on update, no? 15:11:34 pcarver: hi, we're doing only a short meeting / please comment on whatever you want 15:12:11 doude: the only thing that validate port checks is that the port exists => since port_id is read-only, no need to check on update again 15:12:44 we can group everything in one method, but I don't think it really is a huge improvement 15:12:58 doude: ^, do you think this matters a lot ? 15:13:17 ha ok I missed that the port_id cannot be update in a port assoc 15:13:24 ok not it's correct 15:17:42 doude: ok 15:17:59 I don't have anything precise to discuss today 15:18:06 ah yes, there is one thing 15:18:24 doude: I updated https://review.openstack.org/#/c/499943/ based on your comments 15:18:27 I think it's ready 15:19:07 but we need one thing : checking that the change of update pre commit dict does not impact OVS driver (the only driver currently using precommit) 15:19:29 so doude, if you can review the new PS that will help 15:19:51 ok 15:20:28 about that tmorin1, I saw in the ML2 plugin a context manager mechanism. I don't know if that can fit here 15:20:57 but I know ml2 have a similar mechanism with pre and post hook to mechanism driver 15:21:13 perhaps there is some code we can use here 15:21:27 or perhaps it's overkill for our need 15:21:32 s 15:22:03 doude: would you have link ? 15:22:36 (I know that we need to use the more recent DB facade in BGPVPN, but its probably not what you have in mind here) 15:22:43 * doude tries to find it again 15:23:08 ha yes I also see that new DB facade 15:25:10 tmorin1 something like that https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L409 15:25:47 if I understand correctly, that permits to rollback in case an error appear during the hook call to MD 15:26:57 doude: I think this method is more about how to behave when calling multiple drivers and one fails, isn't it ? 15:27:16 doude: the ML2 DB code is not (I think) in the MD manager 15:27:33 ha ok my bad 15:27:47 I think the pattern for pre/post commit hooks wrt to DB calls was borrowed from ML2 by matrohon at the time 15:28:00 so I expect that we already have code similar to ML2 15:34:26 tmorin1: there is a context per resource mechanise, ie. the port case https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L561 15:34:50 but not sure is necessary in our case, we don't have to mange multiple driver 15:41:32 ok 15:41:33 sorry 15:41:36 I was interrupted 15:41:47 I'm not sure we have thing important to discuss this week 15:42:01 there are a few things in the pipe, but the discussion is happening via gerrit in most cases 15:42:07 I propose to close the meeting 15:42:12 thanks doude! 15:42:23 #endmeeting