The image approach works fine if Trove only supports deploying a single datastore type (mysql in your case). As soon as we support deploying more than 1 datastore type, Trove needs to have some knowledge of which guestagent manager classes to load. Hence the need for having a datastore type API.
The argument for needing to keep track of the version is similar. Potentially a version increment -- especially of the major version -- may require for a different guestagent manager. And Trove needs to have this information. Hope this helps, Cheers, -Nikhil Kevin Conway writes: > What is the major motivation not to simply use a glance image named "MySQL > 5.5" or "MongoDB 2.4"? > > Wouldn't that give service providers all the flexibility they need for > providing different types? For example, I could offer a simple "MySQL" > image that creates a MySQL instance. If all my users use the one "MySQL" > image then I can update that image deploy the latest version (or any > version that I, as the service provider, want to deploy). Alternatively, > my users could have a choice of versions if I roll a "MySQL 5.1" and > "MySQL 5.5" image. > > Want to deactivate a version: delete the image. Want to offer a new > version: create a new image. > > It seems like this is parallel to a NOVA deploy offering multiple version > of the same OS (Ubuntu 12 vs Ubuntu 13). Images work nicely for that. Why > couldn't they work for us? > > On 10/21/13 3:12 PM, "Michael Basnight" <mbasni...@gmail.com> wrote: > >> >>On Oct 18, 2013, at 12:30 PM, Tim Simpson wrote: >> >>> 1. I think since we have two fields in the instance object we should >>>make a new object for datastore and avoid the name prefixing, like this: >> >>I agree with this. >> >>> 2. I also think a datastore_version alone should be sufficient since >>>the associated datastore type will be implied: >> >>When i brought this up it was generally discussed as being confusing. Id >>like to use type and rely on having a default (or active) version behind >>the scenes. >> >>> 3. Additionally, while a datastore_type should have an ID in the Trove >>>infastructure database, it should also be possible to pass just the name >>>of the datastore type to the instance call, such as "mysql" or "mongo". >>>Maybe we could allow this in addition to the ID? I think this form >>>should actually use the argument "type", and the id should then be >>>passed as "type_id" instead. >> >>Id prefer this honestly. >> >>> 4. Additionally, in the current pull request to implement this it is >>>possible to avoid passing a version, but only if no more than one >>>version of the datastore_type exists in the database. >>> >>> I think instead the datastore_type row in the database should also have >>>a "default_version_id" property, that an operator could update to the >>>most recent version or whatever other criteria they wish to use, meaning >>>the call could become this simple: >> >>Since we have determined from this email thread that we have an active >>status, and that > 1 version can be active, we have to think about the >>precedence of active vs default. My question would be, if we have a >>default_version_id and a active version, what do we choose on behalf of >>the user? If there is > 1 active version and a user does not specify the >>version, the api will error out, unless a default is defined. We also >>need a default_type in the config so the existing APIs can maintain >>compatibility. We can re-discuss this for v2 of the API. >>_______________________________________________ >>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