203398ae83
Important: We can not use resources abstraction, because we will need an ability to build different graphs for tasks in lifecycle management Also moved all specs to doc/spec directory
53 lines
1.5 KiB
Plaintext
53 lines
1.5 KiB
Plaintext
|
|
Entities
|
|
------------
|
|
We clearly need orchestration entities like:
|
|
1. resources/roles/services/profiles
|
|
|
|
Also we need inventory entities:
|
|
2. nodes/networks/ifaces/cluster/release ?
|
|
|
|
Q: how to allow developer to extend this entities by modules?
|
|
Options:
|
|
1. Use completely schema-less data model
|
|
(i personally more comfortable with sql-like data models)
|
|
2. Dont allow anything except standart entities, if developer needs
|
|
to manage custom data - he can create its own micro-service and
|
|
then integrate it via custom type of resource
|
|
(one which perform query to third-part service)
|
|
|
|
|
|
Identities and namespaces
|
|
---------------------------
|
|
Identities required for several reasons:
|
|
- allow reusage of created once entities
|
|
- provide clear api to operate with entities
|
|
- specify dependencies with identities
|
|
|
|
Will be root namespace polluted with those entities?
|
|
|
|
Options:
|
|
1. We can create some variable namespace explicitly
|
|
2. Or use something like namepsace/entity (example contrail/network)
|
|
|
|
|
|
Multiple options for configuration
|
|
----------------------------------
|
|
|
|
If there will be same parameters defined within different
|
|
modules, how this should behave?
|
|
|
|
1. First option is concatenate several options and make a list of choices.
|
|
2. Raise a validation error that certain thing can be enabled with another.
|
|
|
|
Looks like both should be supported.
|
|
|
|
|
|
Deployment code
|
|
----------------
|
|
|
|
We need to be able to expose all functionality of any
|
|
particular deployment tool.
|
|
|
|
Current challenge: how to specify path to some deployment logic?
|