- 1 Description
- 2 Justification/Benefits
- 3 Use Case Requirements
- 4 Scope
- 5 Impacts
The purpose of this feature is to provide support for Openstack Networking (Neutron) in Trove. Trove has been running on Nova Networking for some time and it is necessary to allow Trove to work in both environments as Neutron gains popularity.
For this implementation Guest Instances will be attached to two Networks. The first Network is passed in by user during a request to create the Instance. The second network is owned by Trove and connects the instance to necessary components of the Trove Control Plane. Currently, the only components of Trove Control Plane that an Instance needs access to is a) RabbitMQ and b) the Internet. The Internet Access here is purely outbound (egress) and allows for the Guest Instance to download packages.
Benefits of Neutron Network
The benefits of using a Private Network for Guest Instances is primarily that there is improved security beyond the use of Security Groups. The Networks for the Guest Instances has specific routing to the Internet and RabbitMQ for RPC. The network that the User provides can either be Public or Private. Best practices in application architecture suggests that you do not place the datastore on a public network. This result is that the Database can be accessed by another node that is one the Internal Network,
Use Case Requirements
Before Installing Trove-Integration/Devstack
- Operator has enable Neutron
- Trove-Integration/DevStack creates a Trove-Network Tenant and User
- Trove-Integration/DevStack creates a Private Network for Guest Instances
Before Trove Instance Creation
- User creates/chooses a Network for which they want the Instance to be attached
- User specifies the Network ID as a parameter to the Instance Create command
During Instance Creation
- Trove provides Trove Private Network ID to Nova when creating the Guest Instance
- After Instance Creation, Trove attaches the Instance to the Customer-specified Network
During Instance Lifespan
Associate Instance with additional Network
- User requests an additional network to be associated with an existing Guest instance.
By introducing neutron client, trove will have the capability of the following operations. (Further support for specific scenarios deserves another blue print though)
Security Group Management
- Trove can utilize Neutron to create and attach secgroup to Guest VMs.
Floating Ip Management
- Trove can allocate/de-allocate floating ip for Guest VMs via Neutron API calls.
The scope of this is primarily limited to Trove API and Task Manager but there is need for support from Trove-Integration in that it must prepare the Tenant and Network so that Trove can handle the first request without additional setup.
This is not backward compatible in the sense that if you have an existing Nova Network based deployment, you could not simply install this feature on top. There are considerable changes to the underlying infrastructure that are well beyond the scope of this enhancement.
Minimal conf value to be added to Trove common.cfg.py
|remote_neutron_client||trove.common.remote.neutron_client||Remote Neutron Client|
|network_manager||trove.network.[nova/neutron].NetworkManager||Switch between nova-network and neutron|
The following feature will only be available if Neutron is enabled and if the Trove Network Tenant is configured. The necessary configurations for Trove API and Taskmanager
|trove_managed_tenant||trove_guest_manager||Tenant Name for Trove which manages Private Network and Instances|
|trove_managed_user||trove_guest_user||User Name for Trove which manages resources|
|trove_managed_password||trove_guest_password||Password used to authenticate Trove User|
|trove_managed_net_id||network_uuid||The private network on which Guest Instances will be attached|
There are no expected changes to the database.
Extra network info will be retrieved by querying against Nova directly.
As mentioned earlier the user will not be able to access Nova directly and gain access to the underlying Nova Instance.
Trove API Instance Create will take an additional parameter which specifies the Network ID.
Trove API Instance Update will take user-specified nic for which they wish to associate additionally with the Guest instance.
By introducing Neutron, an abstract class will be implemented to switch between nova-network and Neutron.
The Net ID will need to be added to the Task Manager call to Create or Update Instance
This change is not backwards compatible with Guest Agents or a deployment for that matter. Changing out the Networking implementation is not trivial. This feature is for greenfield deployments only.
The script for Trove Integration will have to change in such a way that it provides the following infrastructure…
Creates a Trove Tenant and User that is going to Manage the Guest Instances Add configurations to the conf files so that the Tenant, User and Password are available to Trove API and Task Manager Create a Guest Instance Private Network and attach RabbitMQ to that Interface Add Private Network ID to the Configuration file