> 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.
On Mon, Nov 18, 2013 at 1:58 PM, Christopher Armstrong
wrote:
> On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith 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. Sinc
On 11/18/2013 04:58 PM, Christopher Armstrong wrote:
On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith 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 own method for
On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith 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 separate metho
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
> patte
as WIP https://review.openstack.org/#/c/56617/
- Original Message -
> 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
>
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
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
sqlalc
aper.
>
> Regards,
> - Devdatta
>
>
> -Original Message-
> From: "Clayton Coleman"
> Sent: Wednesday, November 13, 2013 12:29pm
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Cc: "devdatta kulkarni&qu
ct: Re: [openstack-dev] [Solum] Some initial code copying for db/migration
- Original Message -
>
> The abstraction will probably always leak something, but in general it comes
> down to isolating a full transaction behind a coarse method. Was going to
> try to demonstrate tha
- Original Message -
>
> The abstraction will probably always leak something, but in general it comes
> down to isolating a full transaction behind a coarse method. Was going to
> try to demonstrate that as I went.
>
I've almost got something ready for feedback and review - before I do
- 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
> 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
:26pm
To: "OpenStack Development Mailing List (not for usage questions)"
Cc: "Dan Smith"
Subject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration
- Original Message -
> >
> > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy
- 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 nov
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 co
On 11/01/2013 05:50 PM, Michael Still wrote:
> On Sat, Nov 2, 2013 at 3:30 AM, Russell Bryant 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
- 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 n
On Sat, Nov 2, 2013 at 3:30 AM, Russell Bryant 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
> projects are either
> 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 s
- 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 tu
- 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_p
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 st
- 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 abstra
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 n
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 cal
- Original Message -
> On 11/01/2013 11:14 AM, Clayton Coleman wrote:
> > - Original Message -
> >> Noorul Islam K M writes:
> >>
> >>> Adrian Otto writes:
> >>>
> Team,
>
> Our StackForge code repo is open, so you may begin submitting code for
> review. For
- 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
>
On 11/01/2013 11:14 AM, Clayton Coleman wrote:
> - Original Message -
>> Noorul Islam K M writes:
>>
>>> Adrian Otto 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 will page with l
29 matches
Mail list logo
