Open Stack

I like #4 over #5 because it seems weird to have to create a configuration
first to see what parameters are allowed. With #4 you could look up what is
allowed first then create your configuration.

Robert
On Jan 22, 2014 10:18 AM, "Craig Vyvial" <cp16net at gmail.com> wrote:

> Hey everyone I have run into an issue with the configuration parameter
> URI. I'd like some input on what the URI might look like for getting the
> list configuration parameters for a specific datastore.
>
> Problem: Configuration parameters need to be selected per datastore.
>
> Currently: Its setup to use the default(mysql) datastore and this wont
> work for other datastores like redis/cassandra/etc.
>
> /configurations/parameters - parameter list for mysql
> /configurations/parameters/<parameter_name> - details of parameter
>
> We need to be able to request the parameter list per datastore. Here are
> some suggestions that outlines how each method may work.
>
> ONE:
>
> /configurations/parameters?datastore=mysql - list parameter for mysql
> /configurations/parameters?datastore=redis - list parameter for redis
>
> - we do not use query parameters for anything other than pagination (limit
> and marker)
> - this requires some finagling with the context to add the datastore.
> https://gist.github.com/cp16net/8547197
>
> TWO:
>
> /configurations/parameters - list of datastores that have configuration
> parameters
> /configurations/parameters/<datastore> - list of parameters for datastore
>
> THREE:
>
> /datastores/<datastore>/configuration/parameters - list the parameters for
> the datastore
>
> FOUR:
>
> /datastores/<datastore> - add an href on the return to the configuration
> parameter list for the datastore
> /configurations/parameters/<datastore> - list of parameters for datastore
>
> FIVE:
>
> * Require a configuration be created with a datastore.
> Then a user may list the configuration parameters allowed on that
> configuration.
>
> /configurations/<config_id>/parameters - parameter list for mysql
>
> - after some thought i think this method (5) might be the best way to
> handle this.
>
>
> I've outlined a few ways we could make this work. Let me know if you agree
> or why you may disagree with strategy 5.
>
> Thanks,
> Craig Vyvial
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/6fc34eb3/attachment.html>