diff --git a/specs/9.0/component-registry-improvements.rst b/specs/9.0/component-registry-improvements.rst new file mode 100644 index 00000000..2dbdd4d5 --- /dev/null +++ b/specs/9.0/component-registry-improvements.rst @@ -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 + * Anton Zemlyanov + +Mandatory design review: + * Igor Kalnitsky + * Vitaly Kramskikh + + +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