Open Stack

+1 to Greg.
Given schema is more preferable for API routes
/datastores/<datastore>/parameters
/datastores/<datastore>/parameters/<parameters>



2014/1/23 Greg Hill <greg.hill at rackspace.com>

>  To be more consistent with other APIs in trove, perhaps:
>
>  /datastores/<datastore>/parameters
>  /datastores/<datastore>/parameters/<parameters>
>
>  Greg
>
>  On Jan 22, 2014, at 4:52 PM, Kaleb Pomeroy <kaleb.pomeroy at rackspace.com>
> wrote:
>
>  I think that may have been a slight oversite. We will likely have the
> following two routes
>
> /datastores/<datastore>/configuration/ would be the collection of all
> parameters
> /datastores/<datastore>/configuration/:parameter would be an individual
> setting.
>
> - kpom
>
>  ------------------------------
> *From:* Craig Vyvial [cp16net at gmail.com]
> *Sent:* Wednesday, January 22, 2014 4:11 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Trove] how to list available
> configuration parameters for datastores
>
>   Ok with overwhelming support for #3.
> What if we modified #3 slightly because looking at it again seems like we
> could shorten the path since /datastores/<datastore>/configuration doesnt
> do anything.
>
>  instead of
> #1
> /datastores/<datastore>/configuration/parameters
>
>  maybe:
> #2
> /datastores/<datastore>/parameters
>
>  #3
> /datastores/<datastore>/configurationparameters
>
>
>
>
> On Wed, Jan 22, 2014 at 2:27 PM, Denis Makogon <dmakogon at mirantis.com>
> wrote:
>
>> Goodday to all.
>>
>>  #3 looks more than acceptable.
>> /datastores/<datastore>/configuration/parameters.
>>  According to configuration parameters design, a configuration set must
>> be associated to exactly one datastore.
>>
>>  Best regards, Denis Makogon.
>>
>>
>> 2014/1/22 Michael Basnight <mbasnight at gmail.com>
>>
>>>  On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote:
>>>
>>> > My thoughts so far:
>>> >
>>> > /datastores/<datastore>/configuration/parameters (Option Three)
>>> > + configuration set without an associated datastore is meaningless
>>> > + a configuration set must be associated to exactly one datastore
>>> > + each datastore must have 0-1 configuration set
>>> > + All above relationships are immediately apparent
>>> > - Listing all configuration sets becomes more difficult (which I don't
>>> think that is a valid concern)
>>>
>>>  +1 to option 3, given what kaleb and craig have outlined so far. I dont
>>> see the above minus as a valid concern either, kaleb.
>>>
>>>
>>>  _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>   _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20140123/2be0642e/attachment.html>