API to fetch configuration of neutron & sub-agents

Registered by Sreekumar S

Neutron clients like Horizon and CLI depend on redundant settings or hard coded values for configurations that are specific to the functionality of neutron and its sub-agents. For example Horizon has settings for 'supported_provider_types', 'segmentation_id_range' and 'extra_provider_types' (proposed). There have been requests/bugs to neutron team to add APIs to fetch these values, so that the API consumers don't have to hard code or add their own configurations and keep in them in sync. In the case of multiple configuration settings, the admin must also know and keep track to set both configurations in his environment.

This blueprint proposes to add a standard identity/role based configuration fetching API for accessing the current exposed configuration. Exposed keys and their corresponding namespaces should be published by neutron and its sub-modules.

Setting or modifying configuration (static or dynamic) is not achievable through the config APIs. For this the client/admin should resort to the individual/specific APIs exposed.

Underlying configuration implementation can also be specific to neutron, it could be configdb, *.ini/*.conf file or anything else.

The neutron config API should expose a unified parent/root namespace from which all other namespaces specific to each sub-agent is accessible.
For example...
/ml2/ml2_type_gre/tunnel_id_ranges -- for ml2 agent
/l3/interface_driver -- for l3 agent
/dhcp/dhcp_driver -- for dhcp agent
/ml2/* -- for ml2 agent

This blue print proposes a new section in network API for 'Configuration' along with 'Networks', 'Subnets', 'Ports', and 'Service providers'.

Example:
GET - /v2.0/config -- List all configuration
GET - /v2.0/config/l3 -- List l3 specific ones.
GET - /v2.0/config/ml2/ml2_type_gre -- List everything under /ml2/ml2_type_gre/*
GET - /v2.0/config/ml2/type_drivers -- Value for 'type_drivers' key inside ml2, returning for eg. "flat,vlan,gre,vxlan"

Such an interface could be followed suit by other projects as well, like may be nova, cinder etc which have their own configuration namespaces to expose.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Sreekumar S
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
Proposed for trunk
Implementation:
Unknown
Milestone target:
milestone icon next
Completed by
Armando Migliaccio

Whiteboard

Nov-30-2015(armax): you've been rejected already. I don't understand why you'd file a blueprint, which you are not even supposed to file.

See RFE submission process:

http://docs.openstack.org/developer/neutron/policies/blueprints.html

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.