FYI, I've raised the new RFE bug that I suggested below:
https://bugs.launchpad.net/neutron/+bug/1486649
Neil
On 18/08/15 23:22, Neil Jerram wrote:
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
