Add database tables to support vendor/product registration.

This specification is the first of a series of specifications that
will be defined for RefStack to implement the vendor/product
registration process.  This spec focus on the data model aspect
of this process.

Change-Id: I59c74367aed3610d71d4221019099a66e8b80178
This commit is contained in:
cdiep 2016-01-18 00:21:20 -08:00
parent 730d2b8202
commit 502d261f11
1 changed files with 222 additions and 0 deletions

View File

@ -0,0 +1,222 @@
Database Tables for Vendor Registration Support
===============================================
Launchpad blueprint: https://blueprints.launchpad.net/refstack/+spec/vendor-result-validation
Requirement document: https://goo.gl/bvo4FG
Data model document: https://goo.gl/zWYnoq
Based on the blueprint and requirement documents listed above, this spec is the
first of a series of specifications that will be defined for RefStack to
implement the vendor registration process. This spec will mainly focus on
the data model aspect of the vendor registration implementation.
Problem description
===================
As RefStack implements the vendor/product registration process, additional
database tables are needed to store the newly added entities such as vendor,
cloud provider, etc. Based on the object model described in the requirement
document, this spec defines the tables and the basic methods/functions needed
to manage them.
Proposed change
===============
The following tables will be added to the RefStack database:
* A table named "organization"
The organization table will store the data representing entities such as
Software Vendors, Cloud Operators, OpenStack Foundation, etc. The various
types of entities stored in this table will be differentiated by the
values stored in the "type" column. These values are pre-defined in a set
of constants (enum) with descriptive names. For example: 1 = foundation,
2 = official_vendor, 3 = private_vendor, etc. There will be only one
organization with the type of "foundation" in a RefStack instance. This
organization will be created by the RefStack admin.
* A table named "product"
This table will contain the product information. Each product must be owned
by a vendor. A "type" column will be used to identify the different types
of products. The types of products are pre-defined constants (enum) with
descriptive names as defined in the OpenStack Marketplace
( http://www.openstack.org/marketplace/). For example: 1 = distro,
2 = public_cloud, 3 = hosted_private_cloud, etc.
Details about these tables are described in the "Data model impact" section.
The following methods will be added:
* Methods to add/remove a vendor and its associated attributes.
* Methods to add/remove a product and its associated attributes.
Alternatives
------------
Auditability is not included in the current implementation. RefStack should
require at least some logging/auditing capability. While RefStack can add richer
auditability features overtime incrementally, at the minimum an updated_by_user
column should be added to the tables to log the last update activity made on an
organization or product entity.
Open to other suggestions.
Data model impact
-----------------
The following tables will be added to the RefStack database.
* "organization" table
+------------------------+-------------+----------+
| Column | Type | |
+========================+=============+==========+
| created_at | datetime | |
+------------------------+-------------+----------+
| deleted_at | datetime | |
+------------------------+-------------+----------+
| deleted | int(11) | |
+------------------------+-------------+----------+
| updated_at | datetime | |
+------------------------+-------------+----------+
| created_by_user | varchar(128)| FK |
+------------------------+-------------+----------+
| id | varchar(36) | PK |
+------------------------+-------------+----------+
| name | varchar(80) | |
+------------------------+-------------+----------+
| description | text | |
+------------------------+-------------+----------+
| type | int(11) | |
+------------------------+-------------+----------+
| group_id | varchar(36) | FK |
+------------------------+-------------+----------+
* "product" table
+------------------------+-------------+----------+
| Column | Type | |
+========================+=============+==========+
| created_at | datetime | |
+------------------------+-------------+----------+
| deleted_at | datetime | |
+------------------------+-------------+----------+
| deleted | int(11) | |
+------------------------+-------------+----------+
| updated_at | datetime | |
+------------------------+-------------+----------+
| created_by_user | varchar(128)| FK |
+------------------------+-------------+----------+
| id | varchar(36) | PK |
+------------------------+-------------+----------+
| name | varchar(80) | |
+------------------------+-------------+----------+
| description | text | |
+------------------------+-------------+----------+
| product_id | varchar(36) | |
+------------------------+-------------+----------+
| type | int(11) | |
+------------------------+-------------+----------+
| public | tinyint(1) | |
+------------------------+-------------+----------+
| organization_id | varchar(36) | FK |
+------------------------+-------------+----------+
| properties | text | |
+------------------------+-------------+----------+
**Notes:**
The value of the product_id field is used for storing a secondary ID to
provide additional information about the cloud, such as a hash of the cloud
access URL. product_id can be initialized at product creation time or later.
The values in the "public" column are boolean numbers indicating whether the
products are privately or publicly visible.
Ideally, the "deleted" column should be of type tinyint(1) (which is a
boolean in SQLAlchemy). Int(11) is used here for being consistent with Oslo.
REST API impact
---------------
None at the database level.
Security impact
---------------
None.
Notifications impact
--------------------
None, for the initial implementation. In the future, RefStack may want to notify the related parties
(users or organizations) when updates are made to these tables.
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Andrey Pavlov
Other contributors:
TBD
Work Items
----------
* Create the tables.
* Create the defined methods.
Dependencies
============
None
Testing
=======
None
Documentation Impact
====================
None
References
==========
None