Indirect access to VMs

Registered by Andrew Lazarev

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

Blueprint information

Status:
Complete
Approver:
Sergey Lukjanov
Priority:
High
Drafter:
Andrew Lazarev
Direction:
Approved
Assignee:
Andrew Lazarev
Definition:
Approved
Series goal:
Accepted for kilo
Implementation:
Implemented
Milestone target:
milestone icon 2015.1.0
Started by
Sergey Lukjanov
Completed by
Sergey Lukjanov

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/indirect-vm-access,n,z

Addressed by: https://review.openstack.org/128475
    Added spec for indirect VMs access

Addressed by: https://review.openstack.org/133131
    Remove unused class and arguments

Addressed by: https://review.openstack.org/133590
    Add indirect VMs access implementation

Addressed by: https://review.openstack.org/136137
    Added documentation for indirect VM access feature

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.