> It's not intuitive to the User, if they are specifying a version alone. You > don't boot a 'version' of something, with specifying what that some thing is. > I would rather they only specified the datastore_type alone, and not have > them specify a version at all.
I agree for most users just selecting the datastore_type would be most intutive. However, when they specify a version it's going to a be GUID which they could only possibly know if they have recently enumerated all versions and thus *know* the version is for the given type they want. In that case I don't think most users would appreciate having to also pass the type- it would just be redundant. So in that case why not make it optional? ________________________________ From: Vipul Sabhaya [vip...@gmail.com] Sent: Monday, October 21, 2013 5:09 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight <mbasni...@gmail.com<mailto:mbasni...@gmail.com>> wrote: On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote: >>> 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? Fair enough. It's not intuitive to the User, if they are specifying a version alone. You don't boot a 'version' of something, with specifying what that some thing is. I would rather they only specified the datastore_type alone, and not have them specify a version at all. > >>> 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. Are you saying you must have a default version defined to have > 1 active versions? I think it makes sense to have a 'Active' flag on every version -- and a default flag for the version that should be used as a default in the event the user doesn't specify. It also makes sense to require the deployer to set this accurately, and if one doesn't exist instance provisioning errors out. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
