Re: [infra][neutron] Removing networking-calico from OpenStack governance
Neil,
networking-calico is the code that integrates Project Calico [1] with Neutron. It has been an OpenStack project for several years, but we, i.e. its developers [2], would like now to remove it from OpenStack governance and instead manage it like the other Project Calico projects under https://github.com/projectcalico/.
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?
On Tue, 2020-02-11 at 13:36 -0500, David Comay wrote:
Neil,
networking-calico is the code that integrates Project Calico [1] with Neutron. It has been an OpenStack project for several years, but we, i.e. its developers [2], would like now to remove it from OpenStack governance and instead manage it like the other Project Calico projects under https://github.com/projectcalico/.
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? networking-calico should not be inheriting form neutron. netuon-lib is fine but the networking-* project should not import form neturon directly.
On Tue, Feb 11, 2020 at 7:08 PM Sean Mooney <smooney@redhat.com> wrote:
Neil,
networking-calico is the code that integrates Project Calico [1] with Neutron. It has been an OpenStack project for several years, but we, i.e. its developers [2], would like now to remove it from OpenStack governance and instead manage it like the other Project Calico projects under https://github.com/projectcalico/.
My primary concern which isn't really governance would be around making sure the components in `networking-calico` are kept in-sync with the
On Tue, 2020-02-11 at 13:36 -0500, David Comay wrote: parent
classes it inherits from Neutron itself. Is there a plan to keep these in-sync together going forward? networking-calico should not be inheriting form neutron. netuon-lib is fine but the networking-* project should not import form neturon directly.
Right, mostly. I think we still inherit from some DHCP agent code that hasn't been lib-ified yet, but otherwise I think it's neutron-lib as you say. (It's difficult to be sure because our code is also written to work with older versions when there was more neutron and less neutron-lib, but that's an orthogonal point.) Best wishes, Neil
Hi David, On Tue, Feb 11, 2020 at 6:43 PM David Comay <david.comay@gmail.com> wrote:
Neil,
networking-calico is the code that integrates Project Calico [1] with Neutron. It has been an OpenStack project for several years, but we, i.e. its developers [2], would like now to remove it from OpenStack governance and instead manage it like the other Project Calico projects under https://github.com/projectcalico/.
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. With that in mind, my plan from now on is: - Continue to stay in touch with our users and customers, so we know what OpenStack versions they want us to support. - As we fix and enhance Calico-specific things, continue CI against the versions that we say we test with. (Currently that means Queens and Rocky - https://docs.projectcalico.org/getting-started/openstack/requirements) - As and when needed, work to support new versions. (Where the first package of work here will be Python 3 support.) WDYT? Does that sounds sensible? Neil
On 2020-02-11 19:31:28 +0000 (+0000), Neil Jerram wrote:
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. [...]
It's probably known to all involved in the conversation here, but just for clarity, the two releases immediately following Rocky (that is, Stein and Train) are still supposed to support Python 2.7. Only as of the Ussuri release (due out in a few more months) will OpenStack be Python3-only. -- Jeremy Stanley
On Tue, Feb 11, 2020 at 7:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
Thanks for this question. I think the answer is that it will be a
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
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
On 2020-02-11 19:31:28 +0000 (+0000), Neil Jerram wrote: planned maintain the
possibility of working with Train and later. [...]
It's probably known to all involved in the conversation here, but just for clarity, the two releases immediately following Rocky (that is, Stein and Train) are still supposed to support Python 2.7. Only as of the Ussuri release (due out in a few more months) will OpenStack be Python3-only.
Sorry; thanks for this correction. (So I should have said "... even the possibility of working with Ussuri and later.") Neil
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.
On Wed, Feb 12, 2020 at 4:52 PM David Comay <david.comay@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.
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@tigera.io> wrote:
On Wed, Feb 12, 2020 at 4:52 PM David Comay <david.comay@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@gmail.com>
participants (5)
-
Chris Morgan
-
David Comay
-
Jeremy Stanley
-
Neil Jerram
-
Sean Mooney