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.
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.
- name: hypervisor:vmware compatible: - name: hypervisor:libvirt:* requires: - name: network:neutron:NSX - name: network:neutron:DVSIn this case both NSX and DVS are required for vmware, but vCenter needs only one of them.
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:
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'
Implement engine for parsing new predicates and other component DSL semantic.
N/A
Plugin developer should clearly describe restriction with core attributes or components in environment_config.yaml file. Change validation to support new format.
N/A
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:
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.
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.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
There is should be notice in plugin SDK about describing restrictions in plugin environment DSL model. Documentation how to use new predicates.
TBD