>> 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. Can't we do both? If a user wants a specific version, most likely they had to enumerate all datastore_versions, spot it in a list, and grab the guid. Why force them to also specify the datastore_type when we can easily determine what that is? >> 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. Imagine that an operator sets up Trove and only has one active version. They then somehow fumble setting up the default_version, but think they succeeded as the API works for users the way they expect anyway. Then they go to add another active version and suddenly their users get error messages. If we only use the "default_version" field of the datastore_type to define a default would honor the principle of least surprise. ________________________________________ From: Michael Basnight [mbasni...@gmail.com] Sent: Monday, October 21, 2013 3:12 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance 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
