[infra][neutron] Removing networking-calico from OpenStack governance

Chris Morgan mihalis68 at gmail.com
Fri Feb 21 20:16:15 UTC 2020


Neil,
  Would it be possible to grab some of your time for a quick conference
call around this issue before anything is changed? David Comay and I should
be available to talk at your convenience some time next week?

Chris

On Wed, Feb 12, 2020 at 1:12 PM Neil Jerram <neil at tigera.io> wrote:

> On Wed, Feb 12, 2020 at 4:52 PM David Comay <david.comay at gmail.com> wrote:
>
>>
>>
>>>> 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.
>>
>
> No efforts that I know of.  The difference is that calico-dhcp-agent is
> driven by information in the Calico etcd datastore, where
> neutron-dhcp-agent is driven via a message queue from the Neutron server.
> I think it has improved since, but when we originated calico-dhcp-agent a
> few years ago, the message queue wasn't scaling very well to hundreds of
> nodes.  We can certainly keep reintegrating in mind as a possibility.
>
>

-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200221/893e1b8f/attachment.html>


More information about the openstack-discuss mailing list