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 [[email protected]] 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
