x/valence-specs
Code Issues Proposed changes

input spec doc for new BP:multi-podmanager

Browse Source 
Change-Id: Idcb86e2947fabee726692c92b29ba52390cdbe98
This commit is contained in:
hubian 2016-11-22 11:37:34 +08:00
parent 13bb3bc603
commit 8db9bafe6d
1 changed files with 175 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

175
specs/ocata/approved/multi-podmanager.rst Normal file
View File

@ -0,0 +1,175 @@
================================
Valence support Multi-PodManager
================================
This proposal adds the ability to dynamically manage pod manager
in valence platform.
BP link : https://blueprints.launchpad.net/openstack-valence/+spec/multi-podm
Problem description
===================
From the architecture level, pod manager now is locked in the config file with
low scalability. This will hinder the development and growth of valence.
From the user case level, there would be some problems that we need to face,
for example:
1. Two or more datacenters with different limitations that it's hard to integrate
all the pod managers into a single one. Such as network limited, long distance
, different assets authority and so on.
2. Users may not good at pod managers, maybe they don't know how to
integrate two or more pod managers into a single one. It has a learning cost.
3. Deploy multiply valences is not a good way to manage all the resources
4. It's not convenient to switch different pod managers.
5. Pod manager vendors want to sell more pod managers and there were not
only one vender. So users would have multiple pod managers before user deploy
valence. If we don't support multi-podm management,that would reflect a gap
and user may unwilling to use Valence.
If Valence could support multi-podm management, these problems were fixed in time.
Also it's the earlier the better to take this into consideration.
Proposed change
===============
Add a Database table to store the pod managers info dynamically as well as
some public api to let admins to do the management operations. Also this
will effect other features like components inventory and compose operation,
they would be need to specify a exist pod manager.
And this would insert Database into valence. This also be a new change. After a
little learning and Chester Kuo's recommendation, etcd DB is a suitable solution.
Alternatives
------------
Integrate all the pods into one pod manager.Let users do the integration.
Valence just lock the one pod manager in the config file.
Data model impact
-----------------
Insert pod manager data and their relations between pod manager and
components(chassis, composedNode, etc). Pod manager database schema may be
like this：
| Columns | type | description |
| :--------: | :------: | :-------------------------------- |
| uuid | varchar | primary key |
| name | varchar | pod manager name |
| url | varchar | full access path of pod manager |
| auth | varchar | str json : authentication info |
| status | varchar | pod manager status:online/offline |
| description | varchar | decribe to pod manager |
| location | varchar | location id string of pod |
| redfish_link | varchar | redfish url of pod manager |
| bookmark_link| varchar | str json : resource bookmark link |
| created_at | datetime | create time |
| updated_at | datetime | update time |
REST API impact
---------------
Add some new public apis:
```
/v1/pod_managers/<string:podm_uuid> :
GET : get podm info by pod manager's uuid
PATCH : update exist podm properties with body : <json:update_items>
DELETE : delete a exist podm by pod managers's uuid
```
```
/v1/pod_managers/:
GET : get pod manager list
POST : add a new podm in the platform with body : <json:create_items>
```
Driver API impact
-----------------
None
Nova driver impact
------------------
None
Security impact
---------------
None
Other end user impact
---------------------
None
Scalability impact
------------------
Much improve valence's scalability
Performance Impact
------------------
None
Other deployer impact
---------------------
This would change the way how pod manager registered into valence. We would register
pod managers in frontend or CLI after Valence service started, instead of configuring
them in config file.
Developer impact
----------------
This will change a lot, because pod manager data is the parent data for exist
components from data structure level.Chassis, rack, composed node are under
a pod manager. And every component shoud have a column to show its pod manager.
Maybe no need to reflect on the API level, but the implementation logics would
have a little improvement. So there would be some impacts on backend private api.
Valence GUI / Horizon impact
----------------------------
Pod managers management site may need to be added.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Bian.Hu
Other contributors:
Andy Yan
Yang Xing
Mao Haijun
Lychee
Wang Zhangdong
Work Items
----------
* DB insert and table create, import sqlalchemy and other required lib.
* API definition，urls design.
* API implementation
* Fix the gap for those effected api
Dependencies
============
None
Testing
=======
* Unit tests: Mocking Pod manager library.
Documentation Impact
====================
* Add new apis to <<API spec doc>>
* Add new doc: <<DB schema>>
References
==========
None