Component registry improvements
Change-Id: I046d67931ca9453eb8864cc4e85d04c0584a8b5a Implements: blueprint component-registry-improvements
This commit is contained in:
parent
cdf5e98f3c
commit
edd8d73ca6
302
specs/9.0/component-registry-improvements.rst
Normal file
302
specs/9.0/component-registry-improvements.rst
Normal file
@ -0,0 +1,302 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
===============================
|
||||||
|
Component registry improvements
|
||||||
|
===============================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/fuel/+spec/component-registry-improvements
|
||||||
|
|
||||||
|
Improve current Fuel component registry functionality [0]_ with possibility of
|
||||||
|
describing complex rules in incompatible/requires relations and restrict plugin
|
||||||
|
sections on `Settings` and `Network` tabs based on it.
|
||||||
|
|
||||||
|
-------------------
|
||||||
|
Problem description
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Currently plugins which provide components can be enabled/disabled after
|
||||||
|
bypassing wizard configuration. For example: if DVS is disabled option on
|
||||||
|
wizard, user still can turn-on it in settings without vmware hypervisor [2]_.
|
||||||
|
Also current components DSL model can't cover complex logical cases. Some of
|
||||||
|
them:
|
||||||
|
|
||||||
|
* `requires` functionality process only `enabled` components. In other words
|
||||||
|
it declares sufficiency condition: if A requires B then B should be
|
||||||
|
enabled (checked or selected on UI). But in case of UI wizard tab when
|
||||||
|
DSL defines: vCenter requires DVS or NSXv network backends, it meens that
|
||||||
|
they should satisfy only necessity condition: if A requires B then B
|
||||||
|
should be present (exist in components list).
|
||||||
|
|
||||||
|
* Logic in compatible/incompatbile/requires relations are very simple and
|
||||||
|
can't cover many cases. For example same case with vCenter, DVS and NSXv.
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
- name: hypervisor:vmware
|
||||||
|
compatible:
|
||||||
|
- name: hypervisor:libvirt:*
|
||||||
|
requires:
|
||||||
|
- name: network:neutron:NSX
|
||||||
|
- name: network:neutron:DVS
|
||||||
|
|
||||||
|
In this case both NSX and DVS are required for vmware, but vCenter needs
|
||||||
|
only one of them.
|
||||||
|
|
||||||
|
|
||||||
|
----------------
|
||||||
|
Proposed changes
|
||||||
|
----------------
|
||||||
|
|
||||||
|
* UI should handle restriction for whole section of specific plugin on
|
||||||
|
`Settings` and `Network` tabs. Current expression logic works out-of-the-box
|
||||||
|
for cheking enabled components in cluster.
|
||||||
|
|
||||||
|
* Extend components DSL model with additional predicates:
|
||||||
|
`one_of` - checks that only one element from list should be processed.
|
||||||
|
`all_of` - checks that all elements from list are processed.
|
||||||
|
`any_of` - checks that any element from list can be processed.
|
||||||
|
`none_of` - checks that none element from list should be processed.
|
||||||
|
|
||||||
|
Each of this predicates can be implmented as function which takes components
|
||||||
|
list to check as argument. In case of False specific message can be raised.
|
||||||
|
|
||||||
|
With such changes the first two problems can be solved smth like this:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
components:
|
||||||
|
- name: hypervisor:libvirt:qemu
|
||||||
|
- name: hypervisor:libvirt:kvm
|
||||||
|
- name: hypervisor:vmware
|
||||||
|
compatible:
|
||||||
|
- name: hypervisor:libvirt:*
|
||||||
|
requires:
|
||||||
|
-
|
||||||
|
any_of:
|
||||||
|
items:
|
||||||
|
- hypervisor:libvirt:qemu
|
||||||
|
- hypervisor:libvirt:kvm
|
||||||
|
message: 'QEMU or KVM should be enabled'
|
||||||
|
-
|
||||||
|
any_of:
|
||||||
|
items:
|
||||||
|
- network:neutron:NSX
|
||||||
|
- network:neutron:DVS
|
||||||
|
message: 'NSX or DVS should to be present'
|
||||||
|
|
||||||
|
|
||||||
|
Web UI
|
||||||
|
======
|
||||||
|
|
||||||
|
Implement engine for parsing new predicates and other component DSL semantic.
|
||||||
|
|
||||||
|
|
||||||
|
Nailgun
|
||||||
|
=======
|
||||||
|
|
||||||
|
Data model
|
||||||
|
----------
|
||||||
|
|
||||||
|
Remove redundant wizard data
|
||||||
|
|
||||||
|
**Release**
|
||||||
|
|
||||||
|
Remove `wizard_metadata` field in based on [1]_
|
||||||
|
|
||||||
|
|
||||||
|
REST API
|
||||||
|
--------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
Orchestration
|
||||||
|
=============
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
RPC Protocol
|
||||||
|
------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
Fuel Client
|
||||||
|
===========
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
Plugins
|
||||||
|
=======
|
||||||
|
|
||||||
|
Plugin developer should clearly describe restriction with core attributes or
|
||||||
|
components in environment_config.yaml file. Change validation to support
|
||||||
|
new format.
|
||||||
|
|
||||||
|
|
||||||
|
Fuel Library
|
||||||
|
============
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
------------
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
* Restrictions for plugin sections can be generated based on incompatible and
|
||||||
|
requires relations, but it's much more complicated implmentation.
|
||||||
|
* Another approach is: implement `expression` logic. It should works in same
|
||||||
|
way as for restrictions. Example:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
components:
|
||||||
|
- name: 'hypervisor:vmware'
|
||||||
|
compatible:
|
||||||
|
- name: 'hypervisor:libvirt:*'
|
||||||
|
restrictions:
|
||||||
|
- condition: "components:hypervisor:libvirt:quemu.value == false
|
||||||
|
or components:hypervisor:libvirt:kvm.value == false"
|
||||||
|
message: "One of QEMU or KVM options required"
|
||||||
|
action: 'disabled'
|
||||||
|
- condition: "not (network:neutron:backend:NSX in components) or
|
||||||
|
not (network:neutron:backend:DVS in components)"
|
||||||
|
message: "NSX or DVS components should be present in system"
|
||||||
|
action: 'disabled'
|
||||||
|
|
||||||
|
In this case we leave `compatible` relation for marking tested components and
|
||||||
|
`restrictions` using instead of `incompatible`/`requires`.
|
||||||
|
|
||||||
|
|
||||||
|
--------------
|
||||||
|
Upgrade impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
New migration for removing wizard metadata is provided. It shouldn't have any
|
||||||
|
impact on data during upgrade because we are not support old wizards and old
|
||||||
|
environment creation.
|
||||||
|
|
||||||
|
|
||||||
|
---------------
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
--------------------
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
---------------
|
||||||
|
End user impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
------------------
|
||||||
|
Performance impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
-----------------
|
||||||
|
Deployment impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
----------------
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
---------------------
|
||||||
|
Infrastructure impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
N/A
|
||||||
|
|
||||||
|
|
||||||
|
--------------------
|
||||||
|
Documentation impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
There is should be notice in plugin SDK about describing restrictions
|
||||||
|
in plugin environment DSL model. Documentation how to use new predicates.
|
||||||
|
|
||||||
|
|
||||||
|
--------------
|
||||||
|
Implementation
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
===========
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
* Andriy Popovych <apopovych@mirantis.com>
|
||||||
|
* Anton Zemlyanov <azemlyanov@mirantis.com>
|
||||||
|
|
||||||
|
Mandatory design review:
|
||||||
|
* Igor Kalnitsky <ikalnitsky@mirantis.com>
|
||||||
|
* Vitaly Kramskikh <vkramskikh@mirantis.com>
|
||||||
|
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
==========
|
||||||
|
|
||||||
|
* [UI] Provide restrictions handling for plugin section based on enabled
|
||||||
|
components.
|
||||||
|
* [UI] Implement engine for any_of|all_of|one_of|none_of predicates.
|
||||||
|
* [Nailgun] Remove wizard metadata form DB model
|
||||||
|
* [Nailgun] Implement engine for predicates for component validation.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
* Component registry [0]_.
|
||||||
|
|
||||||
|
|
||||||
|
------------
|
||||||
|
Testing, QA
|
||||||
|
------------
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
||||||
|
|
||||||
|
Acceptance criteria
|
||||||
|
===================
|
||||||
|
|
||||||
|
* Plugins sections should be locked for enabling/disabling if plugins not
|
||||||
|
compatible with enabled components.
|
||||||
|
|
||||||
|
* Requires functionality for enabled or existed components can be declarative
|
||||||
|
described.
|
||||||
|
|
||||||
|
* User can describe complex logical rules for compatible/incompatible/requires
|
||||||
|
relations.
|
||||||
|
|
||||||
|
|
||||||
|
----------
|
||||||
|
References
|
||||||
|
----------
|
||||||
|
|
||||||
|
.. [0] https://blueprints.launchpad.net/fuel/+spec/component-registry
|
||||||
|
.. [1] https://bugs.launchpad.net/fuel/+bug/1533765
|
||||||
|
.. [2] https://bugs.launchpad.net/fuel/+bug/1527312
|
||||||
|
.. [3] https://bugs.launchpad.net/fuel-plugins/+bug/1537998
|
Loading…
Reference in New Issue
Block a user