[openstack-dev] [neutron] Ipset, merge refactor for J?
Miguel Angel Ajo Pelayo
mangelajo at redhat.com
Thu Sep 18 06:49:37 UTC 2014
Ack, thank you for the feedback. I will put it in WIP until we reach Kilo.
We will track any new bugfixes or changes so the refactor is ready
for early kilo,
then after this is merged I will tackle a second refactor to extract Ipset
out as we planned, into a new driver which extends IptablesFirewallDriver,
here I will need to coordinate with Juergen Brendel from cisco
https://review.openstack.org/#/c/119343/ (ebtables driver)
https://review.openstack.org/#/c/119352/ (ARP fix, based on ebtables)
I also know Jakub Libosvar had good plans to enhance the iptables firewall
driver and testing code so may be it will be good to schedule some meetings
around this starting at Kilo.
I would also like to explore the ebtables driver to extend it with Ipset too.
Best regards,
Miguel Ángel.
----- Original Message -----
> On Tue, Sep 16, 2014 at 7:24 AM, Sean Dague <sean at dague.net> wrote:
> > On 09/16/2014 03:57 AM, Thierry Carrez wrote:
> >> Miguel Angel Ajo Pelayo wrote:
> >>> During the ipset implementatio, we designed a refactor [1] to cleanup
> >>> the firewall driver a bit, and move all the ipset low-level knowledge
> >>> down into the IpsetManager.
> >>>
> >>> I'd like to see this merged for J, and, it's a bit of an urgent matter
> >>> to decide, because we keep adding small changes [2] [3] fruit of the
> >>> early testing which break the refactor, and will add extra work which
> >>> needs to be refactored too.
> >>>
> >>> The advantage of merging now, vs in J, is having K & J share a more
> >>> common
> >>> code base, which would help us during bug backports/etc in the future.
> >>>
> >>> Shihanzhang and I, are happy to see this merge during K, as it doesn't
> >>> incur in functional changes, just code blocks are moved from the iptables
> >>> firewall driver to IpsetManager, and the corresponding tests are moved
> >>> too.
> >>> [...]
> >>
> >> IMHO code refactoring should be considered a superfluous change at this
> >> point in the cycle. The risk/benefit ratio is too high, and focus should
> >> be on bugfixing at this point.
> >
> > +1.
> >
> > Hold the refactoring until Kilo.
> >
> +1
>
> At this point, we should be focusing on bugs which stabilize the
> release. Lets hold this for Kilo.
>
> Thanks,
> Kyle
>
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list