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.mor...@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 <cp16...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Thursday, January 23, 2014 10:55 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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 <imsplit...@gmail.com>wrote: > >> I agree. This keeps everything identical to our current routing scheme. >> On Jan 23, 2014 7:31 AM, "Denis Makogon" <dmako...@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.h...@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.pome...@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 [cp16...@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 <dmako...@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 <mbasni...@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@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
