gistfile1.txt

Quick Points:

- Why configurationRef vs. configuration/configuration_id (i.e. why uri vs. uuid)?
  - I would prefer the id vs. the ref. If going with configurationRef, use underscore vs. camel-case (new style guideline)

pdmars: I think this is just a remnant from how things *were* so updating to the new (underscore) sounds good.
cp16net: made the change to configuration_ref instead of configurationRef
cp16net: I think the _create_ should just require the configuration_id instead of the full uri for a configuration. 

- There is inconsistency in terminology: configurations.values vs. GET /configuration-parameters vs. DB's configuration_items.
  - I would prefer sticking with 'parameters' or 'properties' vs. values/items.

pdmars: I think parameters is used to describe what can be changed in MySQL, values are the actual changes a user has made. At least that's how I view them.

- "There should be two quotas established (1) maximum number of configuration groups per tenant and (2) maximum number of values per configuration group."
  - Why is a limit on values per configuration group necessary or desirable?

pdmars: to keep it within reasonable limits is my guess.

- "When updating the values array, the caller should supply a complete list of values, which will replace the existing array in its entirety."
  - purge-replace as a default is not user friendly (it forces them to GET the current values, then compose on the client-side)

cp16net: This describes the way we should handle the API.
https://gist.github.com/cp16net/ca1d4a77023fb059a9ad/raw/11df89c392eab17049584b86ca8382c8ad5ec0e5/gistfile1.txt
Talking about maybe using PATCH instead of the separate PUT.

- The Configuration Group needs a Service Type (e.g. MySQL), with version-pinning if desired (e.g. MySQL-5.5)
- GET /configuration-parameters needs a Service Type (+ Version)
- GET /configurations should not return a list of instances (unscalable, especially if sharing a default group, and is better served as a filter on GET /instances)

cp16net: I agree this could get out of hand if the list is ever growing. adding a /instances list

- Need the ability to support a reset (to default) on a non-default configuration group

pdmars: this is handled by unassigning the configuration group from the instance, it will (or should IMO) revert to the instances defaults.
cp16net: +1 although we have to find a way to handle know what the default template values are for the flavor.

- For each Service Type (+ version), how will the parameter metadata (configurable, dynamic/static, etc.) be stored? Database? CONF?

cp16net: currently its just a config file that is loaded. minor side note - restart of the service is required for changes.