Open Stack

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/ae0dcb24/attachment.html>