Jump to: navigation, search

Difference between revisions of "Trove/neutron-support"

Line 8: Line 8:
  
 
<gallery>
 
<gallery>
File:Trove-private-network-overview.jpg|Overview of Trove Instances on Private Network
+
File:File2.jpg|Overview of Trove Instances on Neutron Network
File:Trove-nova-neutron-interaction.jpg|Interaction of Trove-Nova
 
 
</gallery>
 
</gallery>
  
 
== Justification/Benefits ==
 
== Justification/Benefits ==
  
=== Benefits of Private Network ===  
+
=== 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,
 
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,
 
=== 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 gaining access to potentially sensitive data. 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 ==  
 
== Use Case Requirements ==  
 
=== Before Installing Trove-Integration/Devstack ===
 
=== Before Installing Trove-Integration/Devstack ===
 
* Operator has enable Neutron  
 
* Operator has enable Neutron  
* Operator has enabled Trove-Managed Instances
 
  
 
=== During Installation ===
 
=== During Installation ===
* Trove-Integration/DevStack creates a Trove-Managed Tenant and User  
+
* Trove-Integration/DevStack creates a Trove-Network Tenant and User  
 
* Trove-Integration/DevStack creates a Private Network for Guest Instances
 
* Trove-Integration/DevStack creates a Private Network for Guest Instances
  
Line 34: Line 29:
  
 
=== During Instance Creation ===
 
=== During Instance Creation ===
* Trove uses a special Nova Client that uses the credentials and network of the Trove-Managed Tenant
+
* Trove provides Trove Private Network ID to Nova when creating the Guest Instance
* After Instance Creation, Trove also attaches the Instance to the Customer-specified Network
+
* After Instance Creation, Trove attaches the Instance to the Customer-specified Network
  
 
=== Other Use Cases ===
 
=== Other Use Cases ===
Line 41: Line 36:
 
==== Restore from Backup ====  
 
==== Restore from Backup ====  
 
* Trove will need to move the port from the old Instance to the new Instance
 
* 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 ==  
 
== Scope ==  
Line 50: Line 41:
  
 
== Impacts ==  
 
== 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.
+
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.
  
 
=== Configuration ===  
 
=== 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
+
This 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
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 76: Line 67:
 
=== Public API ===  
 
=== Public API ===  
 
As mentioned earlier the user will not be able to access Nova directly and gain access to the underlying Nova Instance.  
 
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}
+
Trove API Instance Create will take an additional parameter which specifies the Network ID.
  
 
=== Internal API ===  
 
=== Internal API ===  
This should not affect any interactions between Trove API and Task Manager, Conductor, Guest
+
The Net ID will need to be added to the Task Manager call to Create Instance
  
 
=== Guest Agent ===  
 
=== Guest Agent ===  

Revision as of 22:26, 4 April 2014

Description

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.

Neutron Networks

For this implementation Guest Instances 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 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.

Justification/Benefits

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

During Installation

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

Other Use Cases

Restore from Backup

  • Trove will need to move the port from the old Instance to the new Instance

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

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.

Configuration

This 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

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

There are no expected changes to the database

Public API

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.

Internal API

The Net ID will need to be added to the Task Manager call to Create Instance

Guest Agent

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.

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