Open Stack

Although the DHCP-related patches below are I think very close to mergeable, Brian Haley on IRC queried what, process-wise, motivates merging them now (for Liberty).

I think he's right that something is missing, so I'd like to discuss filling that hole here. What has happened so far is this:

- https://review.openstack.org/#/c/198439/ described 'routed networking', which is the ultimate motivation for these patches. 

- I realised/was told that there should be an RFE bug, per current process, so raised https://bugs.launchpad.net/neutron/+bug/1472704

- Those contributed to the beginning of discussions about supporting 'routed' or 'L3' networks in Neutron - which are ongoing and will take Mitaka at least to refine. 

- Nevertheless, the DHCP-related patches are still valuable now (as explained below) and feasible within the Liberty timescale, so I've continued refining those.

- Discussions, which I believe supported this in principle, took place in neutron-drivers [1][2] and main Neutron [3] IRC meetings.

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-14-15.04.log.html‎

[2]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-21-15.00.log.html

[3] discussion between 14:49:44 and 14:56:49 at http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-28-14.01.log.html

The specific process issue now is that the patches that (IMO) make sense for Liberty reference a bug (1472704) that has a much wider scope and so is quite correctly not approved for Liberty. 

So, what to do? My guess is to raise a new RFE bug that just motivates the DHCP agent support that I'd like to achieve - by way of the existing patches - in the Liberty timescale, ask neutron-drivers to approve that, and update the patches to reference that bug instead. 

Does that sound right?

Regards, 
      Neil 


‎
  Original Message  
From: Neil Jerram
Sent: Monday, 17 August 2015 18:47
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] New networking-calico project

I'd like to announce networking-calico, a new project within the Neutron
stadium to provide OpenStack integration pieces for Project Calico
[1][2]. In a sentence, Calico is a backend that uses routing and
iptables to provide IP-level connectivity between VMs, instead of - as
most Neutron backends do - using bridging to provide an effective L2
broadcast domain. You can read about why that might be interesting at
[1][2], or in more OpenStack-centric terms at [3].

Calico's semantics are not fully describable by the current Neutron API,
and I plan to contribute to API and data model work to address this. 
Discussion about that has already begun at [3] and in the email thread
about 'routed, segmented networks' [4], and I hope it will continue
through the end of this cycle, in Tokyo, and during Mitaka.

For a practical deployment, though, and with some semantic caveats [5],
Calico-style connectivity can be used already in an OpenStack cluster - 
and we have several operator partners interested in and trialling that. 
My team has been developing and refining this since Icehouse, using
Calico-specific patches to Nova and Neutron, but we are now within
touching distance, we think, of working with vanilla OpenStack when
Liberty is released. We released our v1.0 milestone of the core Calico
code last week [14], our Nova patches were merged in July, and we have
the following core Neutron patches currently in review.

[6] https://review.openstack.org/#/c/205181/
[7] https://review.openstack.org/#/c/206078/
[8] https://review.openstack.org/#/c/206077/
[9] https://review.openstack.org/#/c/206079/

These patches have been through many cycles of review - thanks in
particular to Cedric and Oleg - and are now, I believe, fully tested and
polished. They make small generalizations to the DHCP agent code so
that a networking-calico-provided interface driver will be able to use
it, instead of having to provide a parallel DHCP agent implementation. 
I would particularly appreciate if Neutron core reviewers would consider
reviewing and approving [6] and [7] now, as they are the changes that
would be messiest if I had to reimplement them out-of-tree using some
kind of subclassing approach.

Then the plan for networking-calico is that it will contain docs, an ML2
mechanism driver, a DHCP interface driver, and a Devstack plugin for
Calico. These aren't yet at [10], but I will be getting on with that
shortly, and you can already see those pieces in other forms (which will
be retired) at [11], [12] and [13]. Hence, within the next few weeks, I
hope that networking-calico and the vanilla Neutron tree (+ the core
Calico project) will provide a complete demonstration of this kind of
networking.

Looking ahead, we will also set up a regular IRC meeting for people
interested in networking-calico. I'll write again at the time, but
please do let me know if you'd like to be pinged when that is being
arranged.

Many thanks for your attention - please do let me know if you have
questions!

Neil



[1] http://www.projectcalico.org/
[2] http://docs.projectcalico.org/en/latest/
[3] https://review.openstack.org/#/c/198439/
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
[5] http://docs.projectcalico.org/en/latest/calico-neutron-api.html
[10] https://git.openstack.org/cgit/openstack/networking-calico
[11] https://github.com/projectcalico/calico/tree/master/calico/openstack
[12] https://review.openstack.org/#/c/197578/
[13] https://github.com/projectcalico/calico/tree/routed/devstack
[14] http://www.projectcalico.org/announcing-calico-v1-0/


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev