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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
