Stacklight 1.1 not compatible with MOS9.2 features

[Lukasz Pelczyk]

Stacklight 1.1 is not working when new core functionality of MOS9.2 is used ( https://docs.mirantis.com/openstack/fuel/fuel-9.2/release-notes/new-features/service-decomposition.html )

Deployment fails if neutron node is decomposed from controller.
It is caused by lma-main-controller task which is trying to reach to /etc/neutron on Controller node, although neutron is installed on separated node.

Rabbit separation is implemented but compatible with plugin only - https://github.com/openstack/fuel-plugin-detach-rabbitmq
As MOS9.2 offers decomposition of rabbit as its main feature, Stacklight should be able to identify rabbitmq nodes defined by user. Similar situation is with DB decomposition.
From my observation, if user defines rabbit and/or db role names the same way as plugins do (primary-standalone-* / standalone-*), then part of rabbit and db tasks is working fine.

Biggest problem here is the neutron node. I've managed to deploy LMA by moving neutron part of lma-main-controller to separate lma-main-neutron task, although notifications and collectors are not properly configured to monitor neutron node (e.g. nagios is reporting neutron dataplane status as critical although everything is working fine). At the moment I'm trying find and correct tasks and configuration, as MOS9.2 + decomposed neutron + LMA are the crucial needs of our client.

Summary:
1) Do we expect to have LMA1.1 to be compatible with MOS9.2 decomposed controller?
2) Is it possible for LMA1.1 to analyze nodes tags (see roles definition here: http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/configure-environment/decompose-services.html )
3) If answers for 1 and 2 are negative - would be some "official procedure" or workaround provided, which will make LMA1.1 work with decomposed neutron?

[Simon Pasquier (simon-pasquier)]

1) unfortunately StackLight 1.1 will probably never happen, given the current priorities of the project.
2) it should be feasible but see 1)
3) I can't think of any workaround right now that wouldn't involve rebuilding the plugin from modified source.