Clarification of HA / non-HA is useful all the more as the term is currently clearly misleading: assuming that HA is HA only from an OpenStack perspective (and sometimes only on a subset of OpenStack)
As a target system we must validate HA scenario on CI production pods for the release.
Non-HA should be available for developers, it should be an installation option. OPNFVaaS for developer could be based on non-HA solution.
On this topic, I exchanged by mail some month ago on another consideration that has been mentioned during TSC meeting.
We must distinguish generic and specific scenarios.
Specific scenarios are scenarios, usually needed by one project to show a new feature.
The owner is usually clearly identified (the leader of the feature project). It is most of the time dealing with 1 installer. When the feature gains in maturity, the number of installer may increase.
Generic scenarios are
Several features are integrated/tested, the scenario owner is usually by default someone from the installer project
we may imagine a process to merge from specific to generic when the feature managed in specific scenario becomes mature, either by natural integration on upstream (dev integrated in Openstack/ODL/.... in version N+1) or in OPNFV. The second option may require extra work on the installer. Could we today imagine SFC, BGPVN as an installation option in a generic scenario? I think it would make sense but it is not straight forward and require extra collaboration between installer and feature projects.
It is somehow linked to the discussion initiated on release priority regarding possible feature alignment.
It is clear that when a new feature is introduced, the focus is on the feature itself and usually it is linked to 1 installer. After 2 or 3 releases in specific scenario, if the feature is adopted we may expect an wider adoption of the feature by all the installers so the feature will move from experimental to real OPNFV feature (and the it would be easier to certify...)
in other word we may imagine that we validate only generic scenarios and declare the specific scenarios as experimental.
It will also dramatically reduce the number of scenarios and encourage alignment.
It would clarify what an OPNFV release is and keep the flexibility to show new cutting edge features in experimental scenarios.