Indirect access to VMs
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:
- 2015.1.0
- Started by
- Sergey Lukjanov
- Completed by
- Sergey Lukjanov
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Added spec for indirect VMs access
Addressed by: https:/
Remove unused class and arguments
Addressed by: https:/
Add indirect VMs access implementation
Addressed by: https:/
Added documentation for indirect VM access feature