[infra][neutron] Removing networking-calico from OpenStack governance
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...