Open Stack

Hello, Craig.

This short-cut seems like would affect initial design and implementation.
For now we're pinning configuration to datastore (means for all version).
I'd suggest you to elaborate how route changing would change current
validations taking into accout version particular qualities.

Best regards, Denis Makogon.


2014/1/24 Craig Vyvial <cp16net at gmail.com>

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/bb8b07d6/attachment-0001.html>