Trove/trove-managed-instances
Description
This feature makes two changes to the default behavior of Trove.
Private Networks
The first change is that Guest Instances, by default, are will be attached to two Networks. The first Network is that which is given during a request to create the Instance. The second, Network is that which is owned by Trove and connects the instance to specific Trove Infrastructure. Currently, the only pieces of Trove Infrastructure 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 application packages.
Complete Trove Management
The second change is that a system-based Tenant will own all Trove Guest Instances. From a Nova perspective these Instances all belong to a single Tenant but from Trove, these are still owned by the true Customer.
Justification/Benefits
Benefits of Private 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 can on their own Network with only specific routing to Rabbit and the Internet. While the User can provide Trove with a Network that is public (accessible through the Internet), the best practice in the industry is to deploy the Database on a Network that is isolated from external access. This best practice results in a Database that can only be accessed by another node that is one the Internal Network. The two networks can be bridged by a Router.
Benefits of Trove-Owned Instances
Once Trove owns the Instances in Nova, Customers/Users can no longer go directly to Nova to perform functions on the Trove Instances. This prevents issues where a Customer may create an Instance Snapshot and then restore that Snapshot on an unmanaged Instance and thus gaining access to the RabbitMQ. The primary benefit of this feature is that all access and control goes through Trove API. A delegated user in Trove, then performs any actions on the Nova Instance.
Use Case Requirements
Before Installing Trove-Integration/Devstack
- Operator has enable Neutron
- Operator has enabled Trove-Managed Instances
During Installation
- Trove-Integration/DevStack creates a Trove-Managed Tenant and User
- Trove-Integration/DevStack creates a Private Network for Guest Instances
Before Trove Instance Creation
- User creates 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 uses a special Nova Client that uses the credentials and network of the Trove-Managed Tenant
- After Instance Creation, Trove also attaches the Instance to the Customer-specified Network
Other Use Cases
Restore from Backup
- Trove will need to move the port from the old Instance to the new Instance
Quota and Limits
- Quotas and Limits will need to be dramatically increased in Nova since all requests related to Trove Instances, that also require Nova support, will be going through Nova.
- Quotas in Trove will be increasingly important as they will be the only control on a per Tenant level
Scope
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.
Impacts
From a user’s perspective this feature changes some of the expectations and behavior. Most of this is a result of the introduction of Neutron. Neutron allows for highly customized network topologies. This customizations allows users to create networks that better match network architecture standards in a modern world.
Configuration
This feature will only be available if Neutron is enabled and if the Trove Managed feature is configured. The necessary configurations for Trove API and Taskmanager
| configuration name | value | description |
|---|---|---|
| remote_nova_client | trove.managed.remote | replacement Nova Client which uses Trove Tenant creds |
| 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 |
Database
Does this impact any existing tables? If so, which ones? Are the changes forward and backward compatible? Be sure to include the expected migration process There are no expected changes to the database
Public API
- Does this change any API that an end-user has access to?
- Are there any exceptions in terms of consistency with other APIs?
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. This however is being handled in another Blueprint. {insert link to Neutron Blueprint}
Internal API
- Does this change any internal messages between API and Task Manager or Task Manager to Guest
This should not affect any interactions between Trove API and Task Manager or Conductor or Guest
Guest Agent
- Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?
The Guest Agent should not be affected by this change
Trove-Integration
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
