Bug 1152834

Summary: [RFE][sahara]: Indirect access to VMs
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: openstack-saharaAssignee: Elise Gafford <egafford>
Status: CLOSED ERRATA QA Contact: Luigi Toscano <ltoscano>
Severity: high Docs Contact:
Priority: medium    
Version: unspecifiedCC: kbasil, markmc, matt, mimccune, yeylon
Target Milestone: Upstream M2Keywords: FutureFeature, OtherQA
Target Release: 7.0 (Kilo)   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/sahara/+spec/indirect-vm-access
Whiteboard: upstream_milestone_kilo-2 upstream_definition_approved upstream_status_implemented
Fixed In Version: openstack-sahara-2015.1.0-2.el7ost Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-05 13:14:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description RHOS Integration 2014-10-15 04:01:05 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/sahara/+spec/indirect-vm-access.

Description:

Currently there are several ways to give Sahara access to VMs:
1. flat private network (cons: not secure, doesn't work with neutron)
2. floating IPs (cons: all nodes need to have floating IPs (limited resource) and be accessible from controller nodes (several nodes in HA mode); floating IPs are usually for external world, not for access from controller; access to data nodes should be restricted by security rules)
3. net_ns (cons: hard co configure, can be inappropriate) 
4. agents (cons: not implemented yet, requires external message queue accessible from VMs and controllers, requires maintenance of agents) 

This blueprint proposes one more way to access VMs by Sahara. 
Sahara will spawn one more VM (proxy node) and gain access to it using any of methods mentioned above. After that access to all other VMs will be through this proxy VM. This proxy could have really small flavor (cerros or similar).

Pros: we need access to only one VM. 
Cons: additional VM; indirect access could be slower

Specification URL (additional information):

None
Comment 7 errata-xmlrpc 2015-08-05 13:14:45 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1548