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.

    - 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:

    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:

    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:
Mandatory design review:

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.