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" <cp16...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
