Open Stack

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<mailto:cp16net at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/2a0b9575/attachment.html>