Denis, This was slightly modified.
https://blueprints.launchpad.net/trove/+spec/move-manager-to-datastore-version So an instance is correlated one-to-one with a datastore version because we need to the datastore manager to get the templates and the configuration rules because they are located in the same place. The manager can be shared among multiple versions but it could be unique for a version as well which could prove to be useful for version of mysql and other datastores. I hope this make sense. :) Thanks, Craig On Fri, Jan 24, 2014 at 3:29 PM, Denis Makogon <dmako...@mirantis.com>wrote: > 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 <cp16...@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 <cp16...@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.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 >> >> > > _______________________________________________ > 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