Open Stack

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" <mbasnight at 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 at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev