Open Stack

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