Jump to: navigation, search

Difference between revisions of "Trove/trove-managed-instances"

(→‎Description)
(→‎Impacts)
 
(16 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
== Description ==  
 
== Description ==  
  
−
This feature makes two changes to the behavior of Trove.
+
The purpose of this feature is to provide improved control over Compute Instances that are managed by Trove.  Currently, any Trove Instance that a user creates, has two ID and two access points: one through Trove; and the other through Nova.  The point of Trove being to manage datastores in a way that provides a stable and optimized platform.  The option for the user to also configure the Compute Instance directly through Nova compromises this integrity.  The intention here then is to "lock" Compute Instances that were created through the Trove interface.  While this is currently an issue for Trove, other Services that sit on top of Nova can also benefit from this.  *Note* There is a project that is forming called "Service VMs".  In the future this may replace this functionality.
  
−
=== Private Networks ===
+
=== Trove Management ===  
−
The first change is that Guest Instances, by default, 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 packages.
+
The focus of this feature is that a system-based Tenant will own a lock on all Trove Guest Instances.  
−
 
 
−
=== 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.
 
  
 
<gallery>
 
<gallery>
−
File:Trove-private-network-overview.jpg|Overview of Trove Instances on Private Network
+
File:Trove-locked-instances.jpg|Overview of Trove Instances on Management Network
−
File:Trove-nova-neutron-interaction.jpg|Interaction of Trove-Nova
+
File:Trove-locked-instances-interaction.jpg ‎|Interaction of Trove-Nova
 
</gallery>
 
</gallery>
  
 
== Justification/Benefits ==
 
== Justification/Benefits ==
  
−
=== Benefits of Private Network ===
+
=== Benefits of Trove-Locked Instances ===  
−
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,
+
Once Trove locks 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. The Trove API leverages the Trove Admin credentials to Unlock/Lock the Instance during "critical" functions.
−
 
 
−
=== 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 enabled Trove-Managed Instances
 
* 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 Admin Tenant and User.
−
* Trove-Integration/DevStack creates a Private Network for Guest Instances
+
 
 +
=== During Instance Creation ===
  
−
=== Before Trove Instance Creation ===
+
As soon as the Instance is created and found to be in Active status, the Instance will be "locked" by Task Manager.
−
* 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 ===
+
=== During Instance Actions ===
−
* 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
+
For any action requiring action from Nova, Trove API or Task Manager, will unlock the instance.  Then regardless of the outcome, it will lock the instance just before returning a response back to the User.  Such actions would include: Resize and Resize Volume
  
 
=== Other Use Cases ===
 
=== Other Use Cases ===
  
−
==== Restore from Backup ====  
+
==== Security Groups ====  
−
* Trove will need to move the port from the old Instance to the new Instance
+
Security Groups are currently not a lockable resource in Nova.  The result is that the user can still manipulate the Security Groups associated to the the 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 ==  
−
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.
+
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. There will be no resulting changes to public API's nor internal.
  
 
== 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.
+
 
 +
There will be a bit more chattiness to the Trove/Nova interaction. That is, for every call to Nova (unoptimized) would be enclosed in a "unlock/lock" pair. The overhead for this check in Nova is fairly efficient as it simply checks the state in the database and updates the flag.
  
 
=== 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
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
!configuration name!! value !! description  
 
!configuration name!! value !! description  
 
|-
 
|-
−
|remote_nova_client|| trove.managed.remote ||replacement Nova Client which uses Trove Tenant creds
+
|trove.managed.instances|| boolean|| determines whether all instances are owned by Trove (default: false)
−
|-
 
−
|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
 
 
|-
 
|-
 
|}
 
|}
Line 78: Line 58:
  
 
=== 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.
+
There are no changes to the API
−
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 ===  
 
=== Internal API ===  
−
This should not affect any interactions between Trove API and Task Manager, Conductor, Guest
+
There are no changes to the Internal API
  
 
=== Guest Agent ===  
 
=== 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.
+
This will not affect the Guest Agent
  
 
=== Trove-Integration ===  
 
=== Trove-Integration ===  
Line 93: Line 72:
 
Creates a Trove Tenant and User that is going to Manage the Guest Instances
 
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
 
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
 

Latest revision as of 06:55, 28 April 2014

Description

The purpose of this feature is to provide improved control over Compute Instances that are managed by Trove. Currently, any Trove Instance that a user creates, has two ID and two access points: one through Trove; and the other through Nova. The point of Trove being to manage datastores in a way that provides a stable and optimized platform. The option for the user to also configure the Compute Instance directly through Nova compromises this integrity. The intention here then is to "lock" Compute Instances that were created through the Trove interface. While this is currently an issue for Trove, other Services that sit on top of Nova can also benefit from this. *Note* There is a project that is forming called "Service VMs". In the future this may replace this functionality.

Trove Management

The focus of this feature is that a system-based Tenant will own a lock on all Trove Guest Instances.

  • Overview of Trove Instances on Management Network

  • Interaction of Trove-Nova

Justification/Benefits

Benefits of Trove-Locked Instances

Once Trove locks 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. The Trove API leverages the Trove Admin credentials to Unlock/Lock the Instance during "critical" functions.

Use Case Requirements

Before Installing Trove-Integration/Devstack

  • Operator has enabled Trove-Managed Instances

During Installation

  • Trove-Integration/DevStack creates a Trove Admin Tenant and User.

During Instance Creation

As soon as the Instance is created and found to be in Active status, the Instance will be "locked" by Task Manager.

During Instance Actions

For any action requiring action from Nova, Trove API or Task Manager, will unlock the instance. Then regardless of the outcome, it will lock the instance just before returning a response back to the User. Such actions would include: Resize and Resize Volume

Other Use Cases

Security Groups

Security Groups are currently not a lockable resource in Nova. The result is that the user can still manipulate the Security Groups associated to the the 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. There will be no resulting changes to public API's nor internal.

Impacts

There will be a bit more chattiness to the Trove/Nova interaction. That is, for every call to Nova (unoptimized) would be enclosed in a "unlock/lock" pair. The overhead for this check in Nova is fairly efficient as it simply checks the state in the database and updates the flag.

Configuration

configuration name value description
trove.managed.instances boolean determines whether all instances are owned by Trove (default: false)

Database

There are no expected changes to the database

Public API

There are no changes to the API

Internal API

There are no changes to the Internal API

Guest Agent

This will not affect the Guest Agent

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

Retrieved from "https://wiki.openstack.org/w/index.php?title=Trove/trove-managed-instances&oldid=50189"