Open Stack

Looks like there is a "short cut" if you know the datastore version and you
want to look it up.

Exist today in the code:
/datastores/<datastore>/versions/<version>
/datastores/versions/<version>

Add these paths:
/datastores/<datastore>/versions/<version>/parameters
/datastores/<datastore>/versions/<version>/parameters/<parameters>
/datastores/versions/<version>/parameters
/datastores/versions/<version>/parameters/<parameters>

This would the new set of paths for the parameters.

Any objections?


On Fri, Jan 24, 2014 at 2:47 PM, Craig Vyvial <cp16net at gmail.com> wrote:

> Oh shoot. That reminds me i needed to rebase the code i was working on.
>
> And yes this changes things a little because we are using the same
> template paths for the validation_rules as the base template which uses the
> manager field on the datastore_version. This means that we need to make the
> path over the version instead.
>
> /datastores/<datastore>/versions/<version>/parameters
> /datastores/<datastore>/versions/<version>/parameters/<parameters>
>
> Thanks for reminding me Morris.
>
> -Craig
>
>
> On Thu, Jan 23, 2014 at 11:52 PM, Daniel Morris <
> daniel.morris at rackspace.com> wrote:
>
>>   Quick question…
>>
>>  When y'all say that onfiguration set must be associated to exactly one
>> datastore, do you mean datastore or datastore version?  Wouldn't the
>> configuration set available parameters defaults need to be a unique 1-1
>> mapping to a datastore version as they will vary across versions not just
>> the datastore type.  You may have a configurable parameter that exists in
>> MySQL 5.6 that does not exist in MySQL 5.1 or vice versa.  Or am I
>> misunderstanding?
>>
>>  Thanks,
>> Daniel
>>
>>
>>   From: Craig Vyvial <cp16net at gmail.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Thursday, January 23, 2014 10:55 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>>
>> Subject: Re: [openstack-dev] [Trove] how to list available configuration
>> parameters for datastores
>>
>>   I support the latest as well. I will make it so.
>>
>>  Thanks
>>
>>
>> On Thu, Jan 23, 2014 at 8:16 AM, Daniel Salinas <imsplitbit at gmail.com>wrote:
>>
>>> I agree.  This keeps everything identical to our current routing scheme.
>>>  On Jan 23, 2014 7:31 AM, "Denis Makogon" <dmakogon at mirantis.com> wrote:
>>>
>>>>  +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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20140124/11f316d3/attachment.html>