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
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