Merge "Add module mangement to Trove"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
ac1d0a3324
835
specs/mitaka/module-management.rst
Normal file
835
specs/mitaka/module-management.rst
Normal file
@ -0,0 +1,835 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
Sections of this template were taken directly from the Nova spec
|
||||||
|
template at:
|
||||||
|
https://github.com/openstack/nova-specs/blob/master/specs/template.rst
|
||||||
|
|
||||||
|
..
|
||||||
|
This template should be in ReSTructured text. The filename in the git
|
||||||
|
repository should match the launchpad URL, for example a URL of
|
||||||
|
https://blueprints.launchpad.net/trove/+spec/awesome-thing should be named
|
||||||
|
awesome-thing.rst.
|
||||||
|
|
||||||
|
Please do not delete any of the sections in this template. If you
|
||||||
|
have nothing to say for a whole section, just write: None
|
||||||
|
|
||||||
|
Note: This comment may be removed if desired, however the license notice
|
||||||
|
above should remain.
|
||||||
|
|
||||||
|
|
||||||
|
=================
|
||||||
|
Module Management
|
||||||
|
=================
|
||||||
|
|
||||||
|
.. If section numbers are desired, unindent this
|
||||||
|
.. sectnum::
|
||||||
|
|
||||||
|
.. If a TOC is desired, unindent this
|
||||||
|
.. contents::
|
||||||
|
|
||||||
|
Historically, Trove has supported open source databases. As more datastores
|
||||||
|
were added it was inevitable that this would eventually change to include
|
||||||
|
proprietary databases as well. Starting with the Liberty release this is the
|
||||||
|
case (support for Vertica and DB2 now being available) and with this comes the
|
||||||
|
issue of managing the licenses of said databases. In addition, operators may
|
||||||
|
find it useful to include other software on their images that may require
|
||||||
|
'activation' by end-users (for example New Relic's analytical suite). A method
|
||||||
|
of activating this software is also needed.
|
||||||
|
|
||||||
|
The concept of applying a 'license' or 'activation' or 'configuration' of this
|
||||||
|
third-party software is what is referred to herein as 'module' management.
|
||||||
|
|
||||||
|
Launchpad Blueprint:
|
||||||
|
https://blueprints.launchpad.net/trove/+spec/module-management
|
||||||
|
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Users of a particular cloud may be willing to purchase a license to use a
|
||||||
|
datastore from the cloud vendor on a pay-as-you-go based model, and this is the
|
||||||
|
model assumed at the moment (as both Vertica and DB2 redstack images include a
|
||||||
|
fully-functional and licensed database). It is also desirable, however, that
|
||||||
|
users be allowed to 'bring their own license.' In this scenario the user
|
||||||
|
provides a license file that the database requires, and as such a mechanism
|
||||||
|
needs to be in place to 'activate' and/or 'renew' the license through the use
|
||||||
|
of the user provided file.
|
||||||
|
|
||||||
|
This same problem exists for any other proprietary software that an operator
|
||||||
|
may wish to include in their Trove images. These software packages also
|
||||||
|
typically require activation through the use of a license key or file (such as
|
||||||
|
New Relic [1]_) or configuration of some kind.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Trove's responsiblity towards module management will be restricted to the scope
|
||||||
|
of encrypting and storing the required data file (for example, a license file)
|
||||||
|
and providing a way to apply this data to a new or existing Trove instance or
|
||||||
|
cluster. A mechanism will be put in place to allow end users the ability to
|
||||||
|
manage adding, deleting, listing, viewing and updating these module data files.
|
||||||
|
|
||||||
|
Methods to apply, remove, query and retrieve the actual 'module' data file on
|
||||||
|
the Trove instance will also be provided.
|
||||||
|
|
||||||
|
A repeatable option (--module) will be added to the create and cluster-create
|
||||||
|
commands to allow adhoc module selection. In addition, modules can be set to
|
||||||
|
auto-apply, which will have the effect of the Guest Agent installing that
|
||||||
|
module on any instance created with the relevant datastore combination.
|
||||||
|
|
||||||
|
Configuration
|
||||||
|
-------------
|
||||||
|
|
||||||
|
The following configuration changes are anticipated.
|
||||||
|
|
||||||
|
A way of specifying valid module 'types' will be needed for proper validation
|
||||||
|
on module create:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
|
cfg.StrOpt('module_types', default=None,
|
||||||
|
help='A list of module types supported.'),
|
||||||
|
|
||||||
|
A key will be needed in order to be able to encrypt the module data file before
|
||||||
|
storing it in the database:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
|
cfg.StrOpt('module_aes_cbc_key', default='module_aes_cbc_key',
|
||||||
|
help='OpenSSL aes_cbc key for module encryption.'),
|
||||||
|
|
||||||
|
Database
|
||||||
|
--------
|
||||||
|
|
||||||
|
A new table (modules) will be added to the Trove schema:
|
||||||
|
|
||||||
|
================= ============ =========== ==============================
|
||||||
|
Column Type Allow Nulls Description
|
||||||
|
================= ============ =========== ==============================
|
||||||
|
id varchar(36) No ID of module (autogenerated)
|
||||||
|
type varchar(255) No Type of module. This will
|
||||||
|
correlate directly to the
|
||||||
|
required plugin (i.e. a
|
||||||
|
plugin must exist of this
|
||||||
|
'type')
|
||||||
|
tenant_id varchar(36) No ID of tenant to apply
|
||||||
|
module to. 'all' means module
|
||||||
|
applies to all tenants
|
||||||
|
datastore varchar(36) No Name of datastore to apply
|
||||||
|
module to. 'all' means module
|
||||||
|
applies to all datastores
|
||||||
|
datastore_version varchar(36) No Name of datastore version to
|
||||||
|
apply module to. 'all' means
|
||||||
|
module applies to all
|
||||||
|
datastores
|
||||||
|
name varchar(255) No Name of module
|
||||||
|
description varchar(512) Yes Description of module
|
||||||
|
auto_apply tinyint(1) No Should this module be
|
||||||
|
automatically applied during
|
||||||
|
instance/cluster create. Will
|
||||||
|
default to 'no' if not
|
||||||
|
provided
|
||||||
|
visible tinyint(1) No Should this module be
|
||||||
|
visible to non-admin users.
|
||||||
|
Will default to 'yes' if not
|
||||||
|
provided
|
||||||
|
live_update tinyint(1) No Can this module be updated
|
||||||
|
while applied-to instances
|
||||||
|
still exist. If set to 'no'
|
||||||
|
all instances must have the
|
||||||
|
corresponding module removed
|
||||||
|
before it can be updated.
|
||||||
|
Defaults to 'no'
|
||||||
|
contents blob No Encrypted module contents
|
||||||
|
md5 varchar(32) No MD5 hash of module contents
|
||||||
|
created DateTime No Created date
|
||||||
|
updated DateTime No Updated date
|
||||||
|
deleted tinyint(1) Yes Deleted flag
|
||||||
|
deleted_at DateTime Yes Deleted date
|
||||||
|
================= ============ =========== ==============================
|
||||||
|
|
||||||
|
A unique index will be created from the (datastore, datastore_version, name)
|
||||||
|
fields, to allow easy determination of the correct module to apply to a
|
||||||
|
specific instance.
|
||||||
|
|
||||||
|
An MD5 hash of the module contents will be stored in the module record as
|
||||||
|
well. This hash will be reported back when querying the module from a
|
||||||
|
running instance, as the original module record could have been modified with
|
||||||
|
new contents after it was initially applied.
|
||||||
|
|
||||||
|
On installing the module contents on a given instance, a file will be created
|
||||||
|
in a know location using <datastore>-<datastore_version>-<name>.lic as a
|
||||||
|
pattern.
|
||||||
|
|
||||||
|
Creating modules that apply to 'all' tenants or 'all' datastores and ones that
|
||||||
|
are auto-applied will require admin credentials.
|
||||||
|
|
||||||
|
Setting a module to 'not' visible is also an admin-only option. This will
|
||||||
|
allow administrators to 'hide' modules from users if they so desire. Modules
|
||||||
|
that are marked visible=False will not be returned in commands such as list or
|
||||||
|
show unless requested by an admin user. Non-admin users won't be able to apply
|
||||||
|
a non-visible module, however they will still be auto-applied if so designated.
|
||||||
|
|
||||||
|
A new table (instance_modules) will be added to the Trove schema to track which
|
||||||
|
modules have been applied to each instance:
|
||||||
|
|
||||||
|
================= ============ =========== ==============================
|
||||||
|
Column Type Allow Nulls Description
|
||||||
|
================= ============ =========== ==============================
|
||||||
|
id varchar(36) No ID of association
|
||||||
|
(autogenerated)
|
||||||
|
instance_id varchar(36) No ID of instance
|
||||||
|
module_id varchar(36) No ID of module
|
||||||
|
md5 varchar(32) No MD5 hash of module contents
|
||||||
|
created DateTime No Created date
|
||||||
|
updated DateTime No Updated date
|
||||||
|
deleted tinyint(1) Yes Deleted flag
|
||||||
|
deleted_at DateTime Yes Deleted date
|
||||||
|
================= ============ =========== ==============================
|
||||||
|
|
||||||
|
Public API
|
||||||
|
----------
|
||||||
|
|
||||||
|
New ReST API calls will be added to the Trove infrastructure. These fall into
|
||||||
|
two categories - ones to manage the maintenance of the actual modules, and
|
||||||
|
ones to handle the instance interactions.
|
||||||
|
|
||||||
|
In addition, the create and cluster-create calls will be enhanced.
|
||||||
|
|
||||||
|
Module Maintenance
|
||||||
|
..................
|
||||||
|
|
||||||
|
To retrieve a list of all modules that can be applied, the following request
|
||||||
|
would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
GET v1/modules
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'modules' : [
|
||||||
|
{
|
||||||
|
'id': <id>,
|
||||||
|
'type': 'vertica_license',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'vertica',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': '100GB',
|
||||||
|
'description': 'Vertica license for 100GB',
|
||||||
|
'auto_apply': False,
|
||||||
|
'visible': True, # returned for admin only
|
||||||
|
'live_update': False,
|
||||||
|
'md5': <md5>,
|
||||||
|
'created': <date>,
|
||||||
|
'updated': <date>,
|
||||||
|
},
|
||||||
|
{
|
||||||
|
'id': <id>,
|
||||||
|
'type': 'new_relic_activation',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'all',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': 'new_relic',
|
||||||
|
'description': 'New Relic activation',
|
||||||
|
'auto_apply': True,
|
||||||
|
'visible': True, # returned for admin only
|
||||||
|
'live_update': True,
|
||||||
|
'md5': <md5>,
|
||||||
|
'created': <date>,
|
||||||
|
'updated': <date>,
|
||||||
|
},
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
|
||||||
|
Note that an admin user will receive the modules for all tenants, whereas
|
||||||
|
regular users will see modules for their tenant only.
|
||||||
|
|
||||||
|
To retrieve a list of valid modules that can be applied to a specific
|
||||||
|
datastore, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
GET v1/datastores/{datastore_id}/modules
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'modules' : [
|
||||||
|
{
|
||||||
|
'id': <id>,
|
||||||
|
'type': 'new_relic_activation',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'all',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': 'new_relic',
|
||||||
|
'description': 'New Relic activation',
|
||||||
|
'auto_apply': True,
|
||||||
|
'visible': True, # returned for admin only
|
||||||
|
'live_update': True,
|
||||||
|
'md5': <md5>,
|
||||||
|
'updated': <date>,
|
||||||
|
},
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
|
||||||
|
To show the details of a particular module, the following request would be
|
||||||
|
made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
GET v1/modules/<id>
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'id': <id>,
|
||||||
|
'type': 'new_relic_activation',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'all',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': 'new_relic',
|
||||||
|
'description': 'New Relic activation',
|
||||||
|
'auto_apply': True,
|
||||||
|
'visible': True, # returned for admin only
|
||||||
|
'live_update': True,
|
||||||
|
'md5': <md5>,
|
||||||
|
'created': <date>,
|
||||||
|
'updated': <date>,
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
To create a module, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
POST /v1.0/modules
|
||||||
|
{
|
||||||
|
'type': 'vertica_license',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'vertica',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': '100GB',
|
||||||
|
'description': 'Vertica license for 100GB',
|
||||||
|
'auto_apply': False,
|
||||||
|
'visible': False, # admin-only option
|
||||||
|
'live_update': True,
|
||||||
|
'contents': <module_contents>,
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
"module": {
|
||||||
|
'id': <id>,
|
||||||
|
'type': 'vertica_license',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'vertica',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': '100GB',
|
||||||
|
'description': 'Vertica license for 100GB',
|
||||||
|
'auto_apply': False,
|
||||||
|
'visible': False, # returned for admin only
|
||||||
|
'live_update': True,
|
||||||
|
'md5': <md5>,
|
||||||
|
'created': <date>,
|
||||||
|
'updated': <date>,
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
400 Bad Request
|
||||||
|
|
||||||
|
To update a module, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
PATCH /v1.0/modules/{module_id}
|
||||||
|
{
|
||||||
|
'type': 'new_type',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'new_datastore',
|
||||||
|
'datastore_version': 'new_datastore_version',
|
||||||
|
'name': 'new_name',
|
||||||
|
'description': 'new_description',
|
||||||
|
'auto_apply': True,
|
||||||
|
'visible': False, # admin-only option
|
||||||
|
'live_update': True,
|
||||||
|
'contents': <module_contents>,
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
"module": {
|
||||||
|
'id': <id>,
|
||||||
|
'type': 'new_type',
|
||||||
|
'tenant': <id>,
|
||||||
|
'datastore': 'new_datastore',
|
||||||
|
'datastore_version': 'new_datastore_version',
|
||||||
|
'name': 'new_name',
|
||||||
|
'description': 'new_description',
|
||||||
|
'auto_apply': True,
|
||||||
|
'visible': False, # returned for admin only
|
||||||
|
'live_update': True,
|
||||||
|
'md5': <new_md5>,
|
||||||
|
'created': <date>,
|
||||||
|
'updated': <date>,
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
400 Bad Request
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
To delete a module, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
DELETE /v1.0/modules/{module_id}
|
||||||
|
{
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
This operation has no response body
|
||||||
|
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
To query which instances have a particular module applied, the following
|
||||||
|
request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
GET v1/modules/{module_id}/instances
|
||||||
|
{
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'instance': <id>,
|
||||||
|
'modules' : [
|
||||||
|
{
|
||||||
|
'name': '100GB',
|
||||||
|
'id': <id>,
|
||||||
|
'md5': <md5>,
|
||||||
|
'installed': <date>,
|
||||||
|
},
|
||||||
|
{
|
||||||
|
'name': 'new_relic',
|
||||||
|
'id': <id>,
|
||||||
|
'md5': <md5>,
|
||||||
|
'installed': <date>,
|
||||||
|
},
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
Instance Interaction
|
||||||
|
....................
|
||||||
|
|
||||||
|
To apply modules to an instance, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
POST v1/{tenant_id}/instances/{instance_id}/modules
|
||||||
|
{
|
||||||
|
'modules' : [
|
||||||
|
{
|
||||||
|
"id": <id>,
|
||||||
|
},
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'type': 'vertica_license',
|
||||||
|
'datastore': 'vertica',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': '100GB',
|
||||||
|
'md5': <md5>,
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
202 Success
|
||||||
|
400 Bad Request
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
To query an instance about installed modules, the following request would be
|
||||||
|
made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
GET v1/{tenant_id}/instances/{instance_id}/modules
|
||||||
|
{
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'modules' : [
|
||||||
|
{
|
||||||
|
'type': 'vertica_license',
|
||||||
|
'datastore': 'vertica',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': '100GB',
|
||||||
|
'filename': 'vertica-all-100GB.lic',
|
||||||
|
'md5': <md5>,
|
||||||
|
'installed': <date>,
|
||||||
|
'status': 'OK',
|
||||||
|
'error_message': None,
|
||||||
|
},
|
||||||
|
{
|
||||||
|
'type': 'new_relic_activation',
|
||||||
|
'datastore': 'all',
|
||||||
|
'datastore_version': 'all',
|
||||||
|
'name': 'new_relic',
|
||||||
|
'filename': 'all-all-new_relic.lic',
|
||||||
|
'md5': <md5>,
|
||||||
|
'installed': <date>,
|
||||||
|
'status': 'FAILED',
|
||||||
|
'error_message': 'New Relic binaries not found',
|
||||||
|
},
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
To retrieve a module from an instance, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
GET v1/{tenant_id}/instances/{instance_id}/modules/{module_id}
|
||||||
|
{
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
'filename': 'vertica-all-100GB.lic',
|
||||||
|
'contents': <module_contents>,
|
||||||
|
'md5': <md5>,
|
||||||
|
}
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
200 Success
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
To delete a module from an instance, the following request would be made:
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
DELETE v1/{tenant_id}/instances/{instance_id}/modules/{module_id}
|
||||||
|
{
|
||||||
|
}
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
This operation has no response body
|
||||||
|
|
||||||
|
Response Codes::
|
||||||
|
|
||||||
|
202 Success
|
||||||
|
404 Not Found
|
||||||
|
|
||||||
|
Creation Enhancements
|
||||||
|
.....................
|
||||||
|
|
||||||
|
The instance create API will be enhanced to include a module field, containing
|
||||||
|
a list of modules to apply. These will be sent down during the normal
|
||||||
|
'prepare' call and the appropriate plugin called once this instance has been
|
||||||
|
provisioned correctly.
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
|
{
|
||||||
|
'modules' : [
|
||||||
|
{
|
||||||
|
"id": <id>,
|
||||||
|
},
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
In a similar manner, the cluster create API will also be enhanced to include
|
||||||
|
module information in the instances field, as is currently done with flavors,
|
||||||
|
AZs, etc.
|
||||||
|
|
||||||
|
|
||||||
|
Public API Security
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Since the file will be transmitted clear text across the management
|
||||||
|
network, there is a chance that the module can be intercepted if the network
|
||||||
|
is compromised.
|
||||||
|
|
||||||
|
It should be ensured that each plugin created does not 'execute' the contents
|
||||||
|
of the supplied module data file, as this would present the opportunity for a
|
||||||
|
security breach. This seems unlikely though (and will not be the case for the
|
||||||
|
proposed implementations) as most module data files will be passed to another
|
||||||
|
process for validation, and it is up to that process to ensure proper security
|
||||||
|
is maintained. Code reviews will be vital to make sure no plugin accidentally
|
||||||
|
executes this data.
|
||||||
|
|
||||||
|
Python API
|
||||||
|
----------
|
||||||
|
|
||||||
|
New methods will be added to the Python API to facilitate the licensing.
|
||||||
|
A few existing methods will need to be extended as well.
|
||||||
|
|
||||||
|
Module Maintenance
|
||||||
|
..................
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
|
def module_list(self, datastore=None):
|
||||||
|
"""Get a list of all modules that can be applied. Return only
|
||||||
|
those that apply to the datastore if it is passed in.
|
||||||
|
"""
|
||||||
|
|
||||||
|
def module_list_instances(self, module):
|
||||||
|
"""Get a list of all instances that have a given module applied."""
|
||||||
|
|
||||||
|
def module_show(self, module):
|
||||||
|
"""Show the details of the module."""
|
||||||
|
|
||||||
|
def module_create(self, module_type, name, description, contents,
|
||||||
|
datastore, datastore_version='all', auto_apply=False,
|
||||||
|
all_tenants=False, visible=True, live_update=False):
|
||||||
|
"""Create a new module."""
|
||||||
|
|
||||||
|
def module_update(self, module, module_type=None, name=None,
|
||||||
|
description=None, contents=None, datastore=None,
|
||||||
|
datastore_version=None, auto_apply=None,
|
||||||
|
all_tenants=None, visible=None, live_update=None):
|
||||||
|
"""Update an existing module."""
|
||||||
|
|
||||||
|
def module_delete(self, module):
|
||||||
|
"""Delete a module."""
|
||||||
|
|
||||||
|
Instance Interaction
|
||||||
|
....................
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
|
def module_apply(self, instance, modules):
|
||||||
|
"""Apply modules to an instance."""
|
||||||
|
|
||||||
|
def module_query(self, instance):
|
||||||
|
"""Query an instance about installed modules."""
|
||||||
|
|
||||||
|
def module_retrieve(self, instance, module=None, filename=None):
|
||||||
|
"""Retrieve the module data file from an instance and save it in
|
||||||
|
filename. If module is not supplied, retrieve all the modules.
|
||||||
|
If filename is not supplied, use the generated filename found
|
||||||
|
on the instance.
|
||||||
|
"""
|
||||||
|
|
||||||
|
def module_remove(self, instance, module):
|
||||||
|
"""Remove a module from an instance."""
|
||||||
|
|
||||||
|
Creation Enhancements
|
||||||
|
.....................
|
||||||
|
|
||||||
|
For instance.create, the modules field will be added to the call:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
|
def create(self, name, flavor_id, volume=None, databases=None, users=None,
|
||||||
|
restorePoint=None, availability_zone=None, datastore=None,
|
||||||
|
datastore_version=None, nics=None, configuration=None,
|
||||||
|
replica_of=None, slave_of=None, replica_count=None,
|
||||||
|
modules=None):
|
||||||
|
"""Create (boot) a new instance."""
|
||||||
|
|
||||||
|
For cluster.create, the modules field will be added to the
|
||||||
|
['cluster']['instances'] data structure that is already being passed in.
|
||||||
|
|
||||||
|
CLI (python-troveclient)
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
The following Trove CLI commands (upon completion) will be fully functional
|
||||||
|
|
||||||
|
- module-list Displays all modules for the tenant.
|
||||||
|
- module-show Shows details for a particular module resource.
|
||||||
|
- module-create Creates a new module resource.
|
||||||
|
- module-update Updates module details for a particular module
|
||||||
|
resource.
|
||||||
|
- module-delete Delete a module resource.
|
||||||
|
|
||||||
|
- module-apply Apply the given modules to a Trove instance.
|
||||||
|
- module-query Query the given Trove instance for any installed
|
||||||
|
modules.
|
||||||
|
- module-retrieve Retrieves the current modules from a Trove instance.
|
||||||
|
- module-remove Remove a module from a Trove instance.
|
||||||
|
|
||||||
|
- create --module [--module]
|
||||||
|
Creates a new instance and applies the given modules.
|
||||||
|
|
||||||
|
- cluster-create --instance=module=<id>[,module=<id>]
|
||||||
|
Creates a new cluster and applies the given modules to
|
||||||
|
each instance.
|
||||||
|
|
||||||
|
Internal API
|
||||||
|
------------
|
||||||
|
|
||||||
|
Changes also need to be made to the internal API to include any module IDs as
|
||||||
|
a part of the message body that is sent to the task manager.
|
||||||
|
|
||||||
|
The API server will need to make calls to the Guest Agent for the instance
|
||||||
|
interaction type commands.
|
||||||
|
|
||||||
|
Guest Agent
|
||||||
|
-----------
|
||||||
|
|
||||||
|
In the Guest Agent, the modules will be managed with a plugin style
|
||||||
|
architecture based on the stevedore.driver.DriverManager paradym. Each plugin
|
||||||
|
will need to implement 'apply', 'query' and 'remove' actions. The 'query'
|
||||||
|
action will need to report the status of the module 'apply' action. This
|
||||||
|
would report (at a minimum) 'OK' or 'FAILED' plus any other state that seems
|
||||||
|
reasonable for users of the relevant software. If possible, the
|
||||||
|
'error_message' field should be filled with useful information if an error
|
||||||
|
occurs.
|
||||||
|
|
||||||
|
A simple plugin 'base class' that defines the contract will be provided. It
|
||||||
|
will also provide functionality such as placing the file contents into a
|
||||||
|
specified location and retrieving the file will be added. This can be used
|
||||||
|
as the basis for all other plugins.
|
||||||
|
|
||||||
|
The Guest Agent code will use the module 'type' to determine if a plugin exists
|
||||||
|
for the given module. If no plugin can be found, then an error will be written
|
||||||
|
to the log and processing stopped.
|
||||||
|
|
||||||
|
To provide a concrete, real-world plugin implementation, a Vertica license
|
||||||
|
module plugin will be created to allow licenses to be applied to a Vertica
|
||||||
|
datastore. A New Relic plugin will also be created to illustrate activation of
|
||||||
|
other third party software on a guest image.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Dashboard Impact (UX)
|
||||||
|
=====================
|
||||||
|
|
||||||
|
A multi-dropdown will need to be added to the instance create dialog that
|
||||||
|
contains all modules for the selected datastore. These modules, along with
|
||||||
|
any auto-apply ones, will need to be sent along on the create call. The same
|
||||||
|
will be needed for the cluster create dialog.
|
||||||
|
|
||||||
|
A module detail panel will need to be created. This panel will have fields
|
||||||
|
representing the attributes of a module (see module-create command).
|
||||||
|
|
||||||
|
A 'modules' list panel will need to be created. This will have buttons for
|
||||||
|
'delete' and 'update' and will have a link to the detail page for each listed
|
||||||
|
module. This will be a high-level panel, similar to 'Instances.'
|
||||||
|
|
||||||
|
The instance list panel will need to have a new action added: 'apply module.'
|
||||||
|
This will cause a pop-up where the available modules are displayed. The
|
||||||
|
selected module will then be passed in to the module-apply command.
|
||||||
|
|
||||||
|
The instance detail panel will need to run 'module-query' and display the
|
||||||
|
results in a new section 'modules.' Alternately, a link could be placed here
|
||||||
|
that would open a module list panel with the results of the 'module-query'
|
||||||
|
call. Here, buttons for 'module-remove' and 'module-retrieve' would be
|
||||||
|
needed.
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
[peterstac]
|
||||||
|
|
||||||
|
Milestones
|
||||||
|
----------
|
||||||
|
|
||||||
|
Mitaka
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
The work will be undertaken with the following tasks:
|
||||||
|
|
||||||
|
* Client (Python and CLI) changes
|
||||||
|
* Server (API) changes
|
||||||
|
* Guest Agent module plugin infrastructure
|
||||||
|
* Vertica/New Relic plugin implementation
|
||||||
|
|
||||||
|
|
||||||
|
Upgrade Implications
|
||||||
|
====================
|
||||||
|
|
||||||
|
Since this change is net-new, no upgrade issues are expected.
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Generic int-tests will be written, however these will not be run under MySQL
|
||||||
|
testing as it requires no module-based handling.
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
This is a net-new feature, and as such will require documentation.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [1] nrsysmond-config --set license_key=<new_relic_key>.
|
||||||
|
|
||||||
|
|
||||||
|
Appendix
|
||||||
|
========
|
||||||
|
|
||||||
|
None
|
||||||
Loading…
Reference in New Issue
Block a user