Hi, It has been a long catch-up day for me. I have looked through the patches. I have some feedback for them but I don't see why we can't shoot for Liberty-3.
Carl On Sun, Aug 23, 2015 at 7:11 PM, Kyle Mestery <[email protected]> wrote: > Thanks Neil, we'll review this during the drivers meeting this week. It's > getting late in the Liberty cycle, but if you can get Brian, Cedric and Carl > to review this and ensure they are onboard, this is the best way to move > forward. Ensuring the L3 team is ok with the direction would make me > comfortable here. > > Thanks! > Kyle > > On Wed, Aug 19, 2015 at 9:42 AM, Neil Jerram <[email protected]> > wrote: >> >> 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: >> > [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
