Open Stack

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 <mestery at mestery.com> 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 <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
>
>
>
> __________________________________________________________________________
> 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
>