Open Stack

>
>> My primary concern which isn't really governance would be around making
>> sure the components in `networking-calico` are kept in-sync with the parent
>> classes it inherits from Neutron itself. Is there a plan to keep these
>> in-sync together going forward?
>>
>
> Thanks for this question.  I think the answer is that it will be a planned
> effort, from now on, for us to support new OpenStack versions.  From Kilo
> through to Rocky we have aimed (and managed, so far as I know) to maintain
> a unified networking-calico codebase that works with all of those
> versions.  However our code does not support Python 3, and OpenStack master
> now requires Python 3, so we have to invest work in order to have even the
> possibility of working with Train and later.  More generally, it has been
> frustrating, over the last 2 years or so, to track OpenStack master as the
> CI requires, because breaking changes (in other OpenStack code) are made
> frequently and we get hit by them when trying to fix or enhance something
> (typically unrelated) in networking-calico.
>

I don't know the history here around `calico-dhcp-agent` but has there been
previous efforts to propose integrating the changes made to it into
`neutron-dhcp-agent`? It seems the best solution would be to make the
functionality provided by the former into the latter rather than relying on
parent classes from the former. I suspect there are details here on why
that might be difficult but it seems solving that would be helpful in the
long-term.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200212/4341a12b/attachment.html>