Open Stack

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 <Neil.Jerram at metaswitch.com>
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:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150823/28e852a1/attachment.html>