Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/19/2013 12:56 AM, Joshua Harlow wrote: Another good article from an ex-coworker that keeps on making more and more sense the more projects I get into... http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern Your mileage/opinion though may vary :) I don't disagree with most of that ar

Re: [openstack-dev] [openstack-manuals] Need some help when "mvn clean generate-sources"

On 08/19/2013 08:12 AM, Tian, Shuangtai wrote: > Hi guys > When do some build on openstack-manuals project,there is error when bulid > 'openstack-compute-admin' ,but others (such as openstack-user, docbkx-example > e.g) are all SUCCESS. > Anybody know why ? > Thanks! Is this reproduceable? I jus

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/18/2013 11:07 PM, Robert Collins wrote: On 19 August 2013 14:22, Jay Pipes wrote: I'm completely with Joshua here - the ORM layer is more often than not a source of bugs and performance issues. If used improperly, yep. http://www.codinghorror.com/blog/2006/06/object-relational-mappin

[openstack-dev] [openstack-manuals] Need some help when "mvn clean generate-sources"

Hi guys When do some build on openstack-manuals project,there is error when bulid 'openstack-compute-admin' ,but others (such as openstack-user, docbkx-example e.g) are all SUCCESS. Anybody know why ? Thanks! Cd openstack-manuals/doc/src/docbkx/openstack-compute-admin mvn clean generate-sources

[openstack-dev] [openstack-manuals] Need some help when "mvn clean generate-sources"

Hi guys When do some build on openstack-manuals project,there is error when bulid 'openstack-compute-admin' ,but others (such as openstack-user, docbkx-example e.g) are all SUCCESS. Anybody know why ? Thanks! Cd openstack-manuals/doc/src/docbkx/openstack-compute-admin mvn clean generate-sources

Re: [openstack-dev] Continuous deployment - significant process change

On 19 August 2013 16:15, John Griffith wrote: > This was pretty well discussed back in April and May IMO. It petered out with no firm consensus AFAICT. Those of us with CD experience are trying to debug the concerns those of us here without CD experience have, so that we can bring the benefits i

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

Another good article from an ex-coworker that keeps on making more and more sense the more projects I get into... http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern Your mileage/opinion though may vary :) Sent from my really tiny device... On Aug 18, 2013, at 8:12 PM, "Robert Collins" m

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

It will be I interesting to see how it works out in nova, correct me if I am wrong but nova has even more onion layers than other openstack projects. For ex: Nova compute <->unified object model <->rpc<->conductor<->sqlalchemy ORM model<->SQL<->your db Is nova moving away from the ORM model or

Re: [openstack-dev] Access to blueprints

Hi Greg, Specification URL is updated with BP document. Any Comments/Suggestions are most welcome. Regards, Balaji.P On Sat, Aug 17, 2013 at 3:32 AM, Regnier, Greg J wrote: > Hi, > > ** ** > > I am logged into Launchpad and I cannot access the url for this blueprint: > https://blueprints.

Re: [openstack-dev] Continuous deployment - significant process change

On Sun, Aug 18, 2013 at 9:10 PM, Christopher Yeoh wrote: > > On Mon, Aug 19, 2013 at 5:51 AM, Robert Collins > wrote: - Stable branch maintenance becoming harder. > > The set of proposals being made to tackle this are: >> - Set a much harder upper bound on commit size - we were saying 500 >> l

Re: [openstack-dev] Continuous deployment - significant process change

On Mon, Aug 19, 2013 at 5:51 AM, Robert Collins wrote: - Stable branch maintenance becoming harder. > The set of proposals being made to tackle this are: > - Set a much harder upper bound on commit size - we were saying 500 > lines, but the recent research paper suggests that saying 200 lines as

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 19 August 2013 14:22, Jay Pipes wrote: >> I'm completely with Joshua here - the ORM layer is more often than not >> a source of bugs and performance issues. > > > If used improperly, yep. http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.htm

Re: [openstack-dev] Proposal oslo.db lib

On Fri, Aug 16, 2013 at 11:36 AM, Monty Taylor wrote: > > > On 08/16/2013 09:52 AM, Boris Pavlovic wrote: > > Hi all, > > > > We (OpenStack contributors) done a really huge and great work around DB > > code in Grizzly and Havana to unify it, put all common parts into > > oslo-incubator, fix bugs,

Re: [openstack-dev] git commit message: change id will before bug/bp when first commit

thank you On Mon, Aug 19, 2013 at 12:52 AM, Jeremy Stanley wrote: > On 2013-08-18 14:25:22 +0800 (+0800), ZhiQiang Fan wrote: > > When submit code review in gerrit, i have been recommended put > > Fixes-Bug: #bug-id/Implement-Blueprint: #bp-desc before chang-id. > > However, when first run git

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes wrote: > On 08/18/2013 09:56 PM, Robert Collins wrote: > >> On 19 August 2013 10:43, Jay Pipes wrote: >> >>> On 08/18/2013 06:08 PM, Joshua Harlow wrote: >>> In my opinion (and just an opinion that I know everyone doesn't share) ORM

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/18/2013 09:56 PM, Robert Collins wrote: On 19 August 2013 10:43, Jay Pipes wrote: On 08/18/2013 06:08 PM, Joshua Harlow wrote: In my opinion (and just an opinion that I know everyone doesn't share) ORM layers are bulky, restrictive and overly complicate and confuse the reader of the cod

Re: [openstack-dev] Gate breakage process - Let's fix! (related but not specific to neutron)

On Sat, Aug 17, 2013 at 9:46 AM, Robert Collins wrote: > On 17 August 2013 23:49, Salvatore Orlando wrote: > > I tend to agree that when the gate for a project is broken, nothing > should > > be merged for that project until the gate jobs are green again. > > In the case of Neutron, making the jo

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/18/2013 07:44 PM, Joshua Harlow wrote: Using an ORM how does the ORM know what attributes u might access (forgive me if this is a documented sqlalchemy pattern/solution). Doesn't it have to give u back the full model since the ORM layer can't predict what u might do with the model object

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 19 August 2013 10:43, Jay Pipes wrote: > On 08/18/2013 06:08 PM, Joshua Harlow wrote: >> >> In my opinion (and just an opinion that I know everyone doesn't share) ORM >> layers are bulky, restrictive and overly complicate and confuse the reader >> of the code (code is read more often than writt

Re: [openstack-dev] All TripleO repositories are now in the openstack/ namespace!

On Aug 18, 2013, at 4:32 PM, Robert Collins wrote: > Thanks to -infra folk over this weekend, we're now in the openstack/ > namespace for gerrit, git etc. > > Anyone consuming these from git - such as trove - will need to update > to pull from the new repository, or you'll get stale code. Thx f

Re: [openstack-dev] Code review study

On 08/15/2013 12:12 PM, Robert Collins wrote: > This may interest data-driven types here. > > https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ > > Note specifically the citation of 200-400 lines as the knee of the > review effectiveness curve: that's lower

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

Using an ORM how does the ORM know what attributes u might access (forgive me if this is a documented sqlalchemy pattern/solution). Doesn't it have to give u back the full model since the ORM layer can't predict what u might do with the model object? Sent from my really tiny device... On Aug 1

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

It would be neat to see what would happen if just the "raw" models were just used directly. Of course this must be treaded careful since I could see it spreading db logic all over. +1 for turning off deferred loads, I think this encourages and actually hides bugs when lazy loads occur on demand

[openstack-dev] All TripleO repositories are now in the openstack/ namespace!

Thanks to -infra folk over this weekend, we're now in the openstack/ namespace for gerrit, git etc. Anyone consuming these from git - such as trove - will need to update to pull from the new repository, or you'll get stale code. We'll give it a week or so and then delete the old repositories from

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/18/2013 06:28 PM, Joe Gordon wrote: On Aug 18, 2013 3:58 PM, "Jay Pipes" mailto:jaypi...@gmail.com>> wrote: > > On 08/18/2013 03:53 AM, Joshua Harlow wrote: >> >> I always just liked SQL as the database abstraction layer ;) >> >> On a more serious note I think novas new object model

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/18/2013 06:08 PM, Joshua Harlow wrote: In my opinion (and just an opinion that I know everyone doesn't share) ORM layers are bulky, restrictive and overly complicate and confuse the reader of the code (code is read more often than written) and require another layer of understanding (a la

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On Aug 18, 2013 3:58 PM, "Jay Pipes" wrote: > > On 08/18/2013 03:53 AM, Joshua Harlow wrote: >> >> I always just liked SQL as the database abstraction layer ;) >> >> On a more serious note I think novas new object model might be a way to go but in all honesty there won't be a one size fits all sol

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

In my opinion (and just an opinion that I know everyone doesn't share) ORM layers are bulky, restrictive and overly complicate and confuse the reader of the code (code is read more often than written) and require another layer of understanding (a layer is useful if it adds good value, I am not s

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

On 17 August 2013 07:01, Russell Bryant wrote: >> Maybe we've grown up to the point where we have to be more careful and >> not introduce >> these kind of features and the maintenance cost of introducing >> experimental features is >> too great. If that is the community consensus, then I'm happy

Re: [openstack-dev] [Neutron] Exceptions in neutron.extension

Exceptions, defined in neutron.extensions are very specific for the code that implements extension. Exceptions defined in neutron.common.exceptions represent common exception classes which are mapped to HTTP error codes. Also, neutron.common.exceptions contain definitions of exceptions specific to

Re: [openstack-dev] Continuous deployment - significant process change

Just when you thought this had been forgotten On 1 May 2013 21:46, Thierry Carrez wrote: > Clint Byrum wrote: >> On 2013-04-30 14:52, Russell Bryant wrote: >>> My biggest concern with this is applying it to an open source project >>> with an unmanaged workforce. Thierry captured it well when

Re: [openstack-dev] Continuous deployment - significant process change

On 1 May 2013 08:12, Sean Dague wrote: > I think the reality is that openstack tree and process is very close to what > the CD folks want. The only thing that's causing some allergy among the core > teams is the idea of features coming in in an off state, versus coming in > default on so they get

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On 08/18/2013 03:53 AM, Joshua Harlow wrote: I always just liked SQL as the database abstraction layer ;) On a more serious note I think novas new object model might be a way to go but in all honesty there won't be a one size fits all solution. I just don't think sqlalchemy is that solution pe

Re: [openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API

On 08/17/2013 03:10 AM, Julien Danjou wrote: On Fri, Aug 16 2013, Jay Pipes wrote: Actually, that's the opposite of what I'm suggesting :) I'm suggesting getting rid of the resource_metadata column in the meter table and using the resource table in joins... I think there's a lot of scenario w

Re: [openstack-dev] [keystone] Help consuming trusts

Hi Steve, It might be a bit late for this, but here's a script I wrote when experimenting with trusts: https://github.com/mhuin/keystone_trust/blob/master/tests/swift_example.sh I hope it'll help you. Matthieu Huin m...@enovance.com - Mail original - | De: "Steven Hardy" | À: opens

Re: [openstack-dev] git commit message: change id will before bug/bp when first commit

On 2013-08-18 14:25:22 +0800 (+0800), ZhiQiang Fan wrote: > When submit code review in gerrit, i have been recommended put > Fixes-Bug: #bug-id/Implement-Blueprint: #bp-desc before chang-id. > However, when first run git commit in a seperate patch branch, > the change-id will generate before bug/bp

Re: [openstack-dev] [Neutron] Exceptions in neutron.extension

thanks, Matt Riedemann On Sun, Aug 18, 2013 at 9:19 PM, Matt Riedemann wrote: > I don't know what's right but for what it's worth I had cleaned up at > least one case like this where the exception was in both common and an > extension: > > *https://bugs.launchpad.net/neutron/+bug/1210276*

Re: [openstack-dev] [Neutron] Exceptions in neutron.extension

I don't know what's right but for what it's worth I had cleaned up at least one case like this where the exception was in both common and an extension: https://bugs.launchpad.net/neutron/+bug/1210276 Seems to me like if more than one extension need the same type of exception and the error mes

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

I always just liked SQL as the database abstraction layer ;) On a more serious note I think novas new object model might be a way to go but in all honesty there won't be a one size fits all solution. I just don't think sqlalchemy is that solution personally (maybe if we just use sqlalchemy core