Sorry for the delay in responding to this...
* Moved the _obj_classes registry magic out of ObjectMetaClass and into
its own method for easier use. Since this is a subclass based
implementation,
having a separate method feels more appropriate for a factory/registry
pattern.
On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith d...@danplanet.com wrote:
Sorry for the delay in responding to this...
* Moved the _obj_classes registry magic out of ObjectMetaClass and into
its own method for easier use. Since this is a subclass based
implementation,
having a
On 11/18/2013 04:58 PM, Christopher Armstrong wrote:
On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith d...@danplanet.com
mailto:d...@danplanet.com wrote:
Sorry for the delay in responding to this...
* Moved the _obj_classes registry magic out of ObjectMetaClass
and into
its
On Mon, Nov 18, 2013 at 1:58 PM, Christopher Armstrong
chris.armstr...@rackspace.com wrote:
On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith d...@danplanet.com wrote:
Sorry for the delay in responding to this...
* Moved the _obj_classes registry magic out of ObjectMetaClass and
into
its
I think the plus of avoiding decorating things isn't really a huge
win, and actually i think takes clarity away.
Hence the (meh) in my list :)
This wasn't really a sticking point when we were getting reviews on the
original base infrastructure, so I'm surprised people are so vehement
now.
With no feedback on remotability so far (we can touch base at F2F next week)
here's a representative sample of the object model with sqlalchemy
implementations approach, without some of the bits that would enable
remotability (primarily the ability to rehydrate an object with the correct
On 11/01/2013 02:21 PM, Clayton Coleman wrote:
- Original Message -
I was blindly assuming we want to pull in eventlet support, with the
implicit understanding that we will be doing some form of timeslicing and
async io bound waiting in the API... but would like to hear others
...@redhat.com
Sent: Wednesday, November 13, 2013 12:29pm
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: devdatta kulkarni devdatta.kulka...@rackspace.com
Subject: Re: [openstack-dev] [Solum] Some initial code copying for
db/migration
- Original Message -
1) Using objects as an abstraction for versioned data:
This seems like a good direction overall, especially from the
point-of-view
of backwards compatibility of consumers of the object. However, after
looking through some
of the objects
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: Dan Smith d...@danplanet.com
Subject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration
- Original Message -
https://github.com/openstack/nova/blob/master/nova/db
1) Using objects as an abstraction for versioned data:
This seems like a good direction overall, especially from the point-of-view
of backwards compatibility of consumers of the object. However, after
looking through some
of the objects defined in nova/objects/, I am not sure if I
- Original Message -
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43
This API and these models are what we are trying to avoid exposing to
the rest of nova. By
On 11/01/2013 05:50 PM, Michael Still wrote:
On Sat, Nov 2, 2013 at 3:30 AM, Russell Bryant rbry...@redhat.com wrote:
I also would not use migrate. sqlalchemy-migrate is a dead upstream and
we (OpenStack) have had to inherit it. For new projects, you should use
alembic. That's actively
On 11/01/2013 12:46 PM, Clayton Coleman wrote:
I was also going to throw in migrate as a dependency and put in the glue
code for that based on common use from ironic/trove/heat. That'll pull in
a few openstack common and config settings. Finally, was going to add a
solum-dbsync command a la
On 11/01/2013 11:14 AM, Clayton Coleman wrote:
- Original Message -
Noorul Islam K M noo...@noorul.com writes:
Adrian Otto adrian.o...@rackspace.com writes:
Team,
Our StackForge code repo is open, so you may begin submitting code for
review. For those new to the process, I made a
- Original Message -
Once all the gitreview stuff is cleaned up I was going to do some purely
mechanical additions.
I heard a few +1 for sqlalchemy with the standard OpenStack abstraction:
solum/db/api.py
manager abstraction for db calls
solum/db/sqlalchemy/api.py
- Original Message -
On 11/01/2013 11:14 AM, Clayton Coleman wrote:
- Original Message -
Noorul Islam K M noo...@noorul.com writes:
Adrian Otto adrian.o...@rackspace.com writes:
Team,
Our StackForge code repo is open, so you may begin submitting code for
On 11/01/2013 12:33 PM, Clayton Coleman wrote:
- Original Message -
Once all the gitreview stuff is cleaned up I was going to do some purely
mechanical additions.
I heard a few +1 for sqlalchemy with the standard OpenStack abstraction:
solum/db/api.py
manager abstraction for db
I think there is a summit topic about what to do about a good 'oslo.db'
(not sure if it got scheduled?)
I'd always recommend reconsidering just copying what nova/cinder and a few
others have for there db structure.
I don't think that has turned out so well in the long term (a 6000+ line
file is
- Original Message -
On 11/01/2013 12:33 PM, Clayton Coleman wrote:
- Original Message -
Once all the gitreview stuff is cleaned up I was going to do some purely
mechanical additions.
I heard a few +1 for sqlalchemy with the standard OpenStack abstraction:
On 11/01/2013 01:39 PM, Clayton Coleman wrote:
- Original Message -
On 11/01/2013 12:33 PM, Clayton Coleman wrote:
- Original Message -
Once all the gitreview stuff is cleaned up I was going to do some purely
mechanical additions.
I heard a few +1 for sqlalchemy with the
- Original Message -
I was blindly assuming we want to pull in eventlet support, with the
implicit understanding that we will be doing some form of timeslicing and
async io bound waiting in the API... but would like to hear others weigh
in before I add the monkey_patch and stub
- Original Message -
I think there is a summit topic about what to do about a good 'oslo.db'
(not sure if it got scheduled?)
Will look.
I'd always recommend reconsidering just copying what nova/cinder and a few
others have for there db structure.
I don't think that has turned
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43
This API and these models are what we are trying to avoid exposing to
the rest of nova. By wrapping these in our NovaObject-based
On Sat, Nov 2, 2013 at 3:30 AM, Russell Bryant rbry...@redhat.com wrote:
I also would not use migrate. sqlalchemy-migrate is a dead upstream and
we (OpenStack) have had to inherit it. For new projects, you should use
alembic. That's actively developed and maintained. Other OpenStack
- Original Message -
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43
This API and these models are what we are trying to avoid exposing to
the rest of nova. By
26 matches
Mail list logo
