yahoo-eng-team team mailing list archive

[Armando Migliaccio <1521868@xxxxxxxxxxxxxxxxxx>]

*** This bug is a duplicate of bug 1416179 ***
    https://bugs.launchpad.net/bugs/1416179

This is somewhat a duplicate of bug 1416179. We provided a rationale as
to why this is a bad idea. The revised version of the proposal is even
worse because it spills out so many backend details that clients ought
to never be aware of. Exposing an API is not a solution to fixing your
coupling. The coupling must be broken in the first place.

On an another note, I would like to think that you're acting in good
faith, but it seems disrespectful to the team that you'd repropose a bug
report that's only recently been rejected, thus taking away time and
energy that could be used elsewhere more effectively.

** This bug has been marked a duplicate of bug 1416179
   [RFE] API to set & get list of provider network types

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1521868

Title:
  [RFE] API to fetch published configurations

Status in OpenStack Dashboard (Horizon):
  New
Status in neutron:
  New

Bug description:
  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 RFE 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 or modify the config
  files themselves.

  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 RFE 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 for configuration fetching could be followed suit by other projects as well, like may be nova, cinder etc which may have their own configuration namespaces to expose.
  It's like an OpenStack equivalent of /proc file system without the set/mod capability.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1521868/+subscriptions