Open Stack

On 17 March 2015 at 14:44, Carl Baldwin <carl at ecbaldwin.net> wrote:

>
> On Mar 15, 2015 6:42 PM, "Salvatore Orlando"
> > * the ML2 plugin overrides several methods from the base "db" class.
> From what I gather from unit tests results, we have not yet refactored it.
> I think to provide users something usable in Kilo we should ensure the ML2
> plugin at least works with the IPAM driver.
>
> Yes, agreed.
>
> > * the current refactoring has ipam-driver-enabled and
> non-ipam-driver-enabled version of some API operations. While this the less
> ugly way to introduce the driver and keeping at the same time the old
> logic, it adds quite a bit of code duplication. I wonder if there is any
> effort we can make without too much yak shaving to reduce that code
> duplication, because in this conditions I suspect it would a hard sell to
> the Neutron core team.
>
> This is a good thing to bring up.  It is a difficult trade off.  On one
> hand, the way it has been done makes it easy to review and see that the
> existing implementation has not been disturbed reducing the short term
> risk.  On the other hand, if left the way it is indefinitely, it will be a
> maintenance burden.  Given the current timing, could we take a two-phased
> approach?  First, merge it with duplication and immediately create a follow
> on patch to deduplicate the code to merge when that is ready?
>
The problem with duplication is that it will make maintenance troubling.
For instance if a bug is found in _test_fixed_ips the bug fixer will have
to know that the same fix must be applied to _test_fixed_ips_for_ipam as
well. I'm not sure we can ask contributors to fix bugs in two places. But
if we plan to deduplicate with a follow-up patch I am on board. I know we'd
have the cycles for that.
Said that, the decision lies with the rest of core team (Carl's and mine
votes do not count here!). If I were a reviewer I'd evaluate the tradeoff
between of the benefits brought buythis new feature, the risks of the
refactoring (which, as you say, are rather low), and the maintenance burden
(aka technical debt) it introduces.

I'm kind of sure the PTL would like to outline all of this, including
extensive details about testing, in an etherpad so that a call could be
made by the end of week.
I am already taking care of that.

Salvatore

Carl
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150317/c1872b5b/attachment.html>