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 <[email protected]<mailto:[email protected]>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<[email protected]<mailto:[email protected]>>
Date: Thursday, January 23, 2014 10:55 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<[email protected]<mailto:[email protected]>>
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 
<[email protected]<mailto:[email protected]>> wrote:

I agree.  This keeps everything identical to our current routing scheme.

On Jan 23, 2014 7:31 AM, "Denis Makogon" 
<[email protected]<mailto:[email protected]>> wrote:
+1 to Greg.
Given schema is more preferable for API routes
/datastores/<datastore>/parameters
/datastores/<datastore>/parameters/<parameters>



2014/1/23 Greg Hill <[email protected]<mailto:[email protected]>>
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 
<[email protected]<mailto:[email protected]>> 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 [[email protected]<mailto:[email protected]>]
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 
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to