[RFE] API to set & get list of provider network types

[Janet Yu]

There is currently no way to get the list of available provider network types from Neutron. The list may vary based on which plugin is used. Allowing clients to query for this list will remove having to hardcode the types in clients such as Horizon.

[Salvatore Orlando (salvatore-orlando)]

This is probably more of a lacking feature on the server side.
Without exposure there for available provider types, the only thing the CLI could do is to return a hardcoded list, which is probably not the right thing to do.

[Eugene Nikanorov (enikanorov)]

I wonder why do we need this feature.
The list of available provider types is specified in configuration, which as available to admin. Provider networks extension is also only available for admin user. So this could add some convenience, but is not required.

[Armando Migliaccio (armando-migliaccio)]

Unless we provide a mechanism to dynamically modify the list of provider networks, returning them does not make much sense, as it's hard-coded.

[Armando Migliaccio (armando-migliaccio)]

There's much more than meets the eye :)

[Akihiro Motoki (amotoki)]

The requested feature consists of two part: set (configure) the get (list) and retrieve the list. We can discuss two separately.

Regarding "get", it is useful to me.
As Horizon or other external system which calls Neutron API, it is useful that neutron provides an API to retrieve available values or value ranges (provider types in this case). Without this feature, Horizon or other system needs to maintain the same list in their configurations. In fact, Horizon maintains network provider lists in its settings. This is completely a work around.
Of course, if we expose this kind of list, we need an appropriate policy.json.
If only administrators can specify some information, it should be limited to administrators in GET API too.
We already expose provider-list or flavor-list for users. In my understanding, this feature request is just an admin version of this.

Regarding "set", I don't see a specific use case at now.
More input would be appreciated.

[Armando Migliaccio (armando-migliaccio)]

Based on discussion that took place on [1], we'll mark this as won't fix. The list of types for a network is hardcoded in the config file. Exposing them via the API to make other systems avoid the hard-coding sounds like an overkill.

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-11-24-15.01.log.html

[Akihiro Motoki (amotoki)]

I still want GET API. what is the criteria of "overkill"?

Horizon team receives the following patches ONLY to sync neutron changes.
From feedbacks in Horizon reviews, horizon reviewers has a consensus that this kind of things should not happen in Horizon and Neutron should expose some API.

Horizon has settings for supported_provider_types, segmentation_id_range and extra_provider_types (proposed).
Mirroring this kind of parameters is unproductive. All of them are unnecessary if neutron has a proper API.

https://review.openstack.org/#/c/233934 Sync segmentation ID ranges with Neutron
https://review.openstack.org/#/c/233933 Add Geneve support
https://review.openstack.org/#/c/232975 Add network types used by midonet

[Armando Migliaccio (armando-migliaccio)]

Developing an API/CLI, tests, docs etc to exposed a hard-coded list of parameters....if that's not an overkill I don't know what is.

[Armando Migliaccio (armando-migliaccio)]

The cost frankly outweighs the benefits.

[Akihiro Motoki (amotoki)]

Okay, nothing to say from API users including horizon side.

I try it again later once Swagger API definitions which is under investigation in Nova or other projects lands.
Once it lands, the cost would be lower than now if more automated way is introduced.

Thanks,

[Armando Migliaccio (armando-migliaccio)]

Again, if that list was not static, I'd agree with you..how frequently does that list needs to change for it to be a pain to handle?

[Sreekumar S (sreesiv)]

Having individual APIs for getting options which are less frequently changed; effort cost is high, agreed!

Having to fix other modules to keep syncing with a particular one, very unproductive indeed! Totally agree with @amotoki.

The solution will be to have a standard RBAC config API for 'fetching' current configuration (static & dynamic ones), which all modules should adhere to. Exposed keys and their namespaces should be published by each module. Setting values can have their own 'individual/specific API' approach. Underlying config implementation can also be specific to each module, can be configdb, ini file or anything else...