Hi Matt, Sorry for the slow response over the winter holidays. First I have to correct myself:
On 12/20/2018 8:02 AM, Bence Romsics wrote:
... in neutron we don't directly control the list of extensions loaded. Instead what we control (through configuration) is the list of service plugins loaded. The 'resource_request' extension is implemented by the 'qos' service plugin. But the 'qos' service plugin implements other API extensions and features too. A cloud admin may want to use these other features of the 'qos' service plugin, but not the guaranteed minimum bandwidth.
This is the default behavior, but it can be overcome by a small patch like this: https://review.openstack.org/627978 With a patch like that we could control loading the port-resource-request extension (and by that the presence of the resource_request attribute) on its own (independently of all other extensions implemented by the qos service plugin). On Thu, Dec 20, 2018 at 6:58 PM Matt Riedemann <mriedemos@gmail.com> wrote:
Can't the resource_request part of this be controlled via policy rules or something similar?
Is this question still relevant given the above? Even if we could control the resource-request attribute via policy rules wouldn't that be just as undiscoverable as a config-only feature flag?
Barring that, are policy rules something that could be used for deployers could decide which users can use this feature while it's being rolled out?
Using a standalone neutron extension (controlled on its own by a neutron config option) as a feature flag (and keeping it not loaded by default until the feature is past experimental) would lessen the number of cloud deployments (probably to zero) where the experimental feature is unintentionally exposed. On the other hand - now that Jay called my attention to the undiscoverability of feature flags - I realize that this approach is not enough to distinguish the complete and experimental versions of the feature, given the experimental version was exposed intentionally. Cheers, Bence