Open Stack

I've been trying to use heat more and ran into similar issues with its metadata server bits not working on private namespaces too. Long term it may need to be made netns aware as well.

Neutron's metadata server is already netns aware with their proxy stuff. It seems to be working reliably for us.

Since multiple projects are needing to do the netns proxy stuff, maybe the Neutron metadata proxy could be made pluggable so that Savanna, Heat, and (Murano?) could plugin to the existing, working mechanisms?

Thanks,
Kevin
________________________________________
From: Matthew Farrellee [matt at redhat.com]
Sent: Thursday, October 03, 2013 8:42 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [savanna] neutron and private networks

On 10/03/2013 11:21 AM, Jon Maron wrote:
> Hi,
>
> I'd like to raise an issue in the hopes of opening some discussion on
> the IRC chat later today:
>
> We see a critical requirement to support the creation of a savanna
> cluster with neutron networking while leveraging a private network
> (i.e. without the assignment of public IPs) - at least during the
> provisioning phase.  So the current neutron solution coded in the
> master branch appears to be insufficient (it is dependent on the
> assignment of public IPs to launched instances), at least in the
> context of discussions we've had with users.
>
> We've been experimenting and trying to understand the viability of
> such an approach and have had some success establishing SSH
> connections over a private network using paramiko etc.  So as long as
> there is a mechanism to ascertain the namespace associated with the
> given cluster/tenant (configuration?  neutron client?) it appears
> that the modifications to the actual savanna code for the instance
> remote interface (the SSH client code etc) will be fairly small.  The
> namespace selection could potentially be another field made available
> in the dashboard's cluster creation interface.
>
> -- Jon

Last week there was an IRC discussion about this, which is by its very
nature rather ephemeral. So thanks for taking this to the list.

The outcome of the IRC meeting was that -

  0) we don't cover the use case where only the cluster's head node has
a public IP (all worker nodes have private IPs)

  1) we think it's an important use case

  2) there are two ways we see to address it
   a) do some architectural changes so that the responsibility of
configuring the cluster can be delegated to the head node (from savanna-api)
   b) make savanna-api netns aware (e.g. ip netns exec) so that it can
contact all nodes no matter the visibility of their network

This is a good item for the roadmap and for a design session in Hong Kong.

Best,


matt

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev