Re: [openstack-dev] [trove] Datastore Type/Version Migration

2014-01-22 Thread Andrey Shestakov
Hi

Looks good approach. Lets start discussion.

I propose API spec for it
https://gist.github.com/andreyshestakov/8559309

Please look it and add your advices and comments.

Thanks

On Thu, Nov 21, 2013 at 2:44 AM, McReynolds, Auston
amcreyno...@ebay.com wrote:
 With Multiple Datastore Types/Versions merged to master, the
 conversation around how to support migrating from one datastore
 version to another has begun.

 Please see https://gist.github.com/amcrn/dfd493200fcdfdb61a23 for
 a consolidation of thoughts thus far.


 ___
 OpenStack-dev mailing list
 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


Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-21 Thread Andrey Shestakov

1. Good point
2. Got this case in irc, and decided to pass type and version together 
to avoid confusing.
3. Names of types and maybe versions can be good, but in irc 
conversation rejected this case, i cant remember exactly reason.

4. Actually, active field in version marks it as default in type.
Specify default version in config can be usefull if you have more then 
one active versions in default type.
But how match active version in type depends on operator`s 
configuration. And what if default version in config will marked as 
inactive?


On 10/18/2013 10:30 PM, Tim Simpson wrote:

Hello fellow Trovians,

There has been some good work recently to figure out a way to specify 
a specific datastore  when using Trove. This is essential to 
supporting multiple datastores from the same install of Trove.


I have an issue with some elements of the proposed solution though, so 
I decided I'd start a thread here so we could talk about it.


As a quick refresher, here is the blue print for this work (there are 
some gists ammended to the end but I figured the mailing list would be 
an easier venue for discussion):

https://wiki.openstack.org/wiki/Trove/trove-versions-types

One issue I have is with the way the instance create call will change 
to support different data stores. For example, here is the post call:



{
  instance : {
  flavorRef : 2,
  name : as,
  datastore_type : e60153d4-8ac4-414a-ad58-fe2e0035704a,
  datastore_version : 94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b,
  volume : { size : 1 }
}
}


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:



{
 instance : {
  flavorRef : 2,
  name : as,
  datastore: {
type : e60153d4-8ac4-414a-ad58-fe2e0035704a,
version : 94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b
  }
  volume : { size : 1 }
}
}


2. I also think a datastore_version alone should be sufficient since 
the associated datastore type will be implied:



{
  instance : {
  flavorRef : 2,
  name : as,
  datastore: {
version : 94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b
  }
  volume : { size : 1 }
}
}


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.



{
  instance : {
  flavorRef : 2,
  name : as,
  datastore: {
type : mysql,
version : 94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b
  }
  volume : { size : 1 }
}
}



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:



{
  instance : {
  flavorRef : 2,
  name : as,
  datastore: {
type : mysql
  }
  volume : { size : 1 }
}
}


Thoughts?

Thanks,

Tim


___
OpenStack-dev mailing list
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


Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-21 Thread Andrey Shestakov
On Mon, Oct 21, 2013 at 11:40 PM, Tim Simpson tim.simp...@rackspace.com wrote:

  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.

if default version is inactive? there will more cases for error

also, i think we have to use default version only if type contains  1
active version. And default version should be active, otherwise -
error.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev