[openstack-dev] [Neutron] - Joining the team - interested in a Debian Developer and experienced Python and Network programmer?

Joe Mcbride jmcbride at rackspace.com
Mon Apr 13 17:45:06 UTC 2015


My apologies to the list. This was not intended to be broadcast.


________________________________________
From: Joe Mcbride
Sent: Monday, April 13, 2015 12:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] - Joining the team - interested in a Debian Developer and experienced Python and Network programmer?

Hi Matt,
Our team at Rackspace is looking to add a developer, focused on building out and deploying Designate (DNSaaS for Openstack). When we go live, we expect to have the largest public deployment, so scaling and migration challenges will be particularly interesting technical problems to solve.

Best of luck on getting into the Neutron fun.

__________________
Joe McBride
Rackspace Cloud DNS
I’m hiring a software developer https://gist.github.com/joeracker/d49030cef6001a8f94d0


________________________________________
From: Matt Grant <matt at mattgrant.net.nz>
Sent: Thursday, April 9, 2015 2:13 AM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Neutron] - Joining the team - interested in a Debian Developer and experienced Python and Network programmer?

Hi!

I am just wondering what the story is about joining the neutron team.
Could you tell me if you are looking for new contributors?

Previously I have programmed OSPFv2 in Zebra/Quagga, and worked as a
router developer for Allied Telesyn.  I also have extensive Python
programming experience, having worked on the DNS Management System.

I have been experimenting with IPv6 since 2008 on my own home network,
and I am currently installing a Juno Openstack cluster to learn ho
things tick.

Have you guys ever figured out how to do a hybrid L3 North/South Neutron
router that propagates tenant routes and networks into OSPF/BGP via a
routing daemon, and uses floating MAC addresses/costed flow rules via
OVS to fail over to a hot standby router? There are practical use cases
for such a thing in smaller deployments.

I have a single stand alone example working by turning off
neutron-l3-agent network name space support, and importing the connected
interface and static routes into Bird and Birdv6. The AMPQ connection
back to the neutron-server is via the upstream interface and is secured
via transport mode IPSEC (just easier than bothering with https/SSL).
Bird looks easier to run from neutron as they are single process than a
multi process Quagga implementation.  Incidentally, I am running this in
an LXC container.

Could some one please point me in the right direction.  I would love to
be in Vancouver :-)

Best Regards,

--
Matt Grant,  Debian and Linux Systems Administration and Consulting
Mobile: 021 0267 0578
Email: matt at mattgrant.net.nz


__________________________________________________________________________
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



More information about the OpenStack-dev mailing list