Open Stack

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