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
On 08/18/2013 11:07 PM, Robert Collins wrote:
On 19 August 2013 14:22, Jay Pipes jaypi...@gmail.com 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.
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 just
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
On 19 August 2013 18:35, Jay Pipes jaypi...@gmail.com wrote:
http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html
There is no proper use of an ORM.
I'm not a super-fan of ORMs, Robert. I'm not sure why you're insisting on
taking me down
On 08/18/2013 10:33 PM, Joe Gordon wrote:
An alternative I think would be better would be to scrap the use of
the SQLAlchemy ORM; keep using the DB engine abstraction support.
+1, I am hoping this will provide noticeable performance benefits while
being agnostic of what DB
I'm throwing this up here to get some feedback on something that's
always bugged me about the model base used in many of the projects.
There's a mixin class that looks like so:
class SoftDeleteMixin(object):
deleted_at = Column(DateTime)
deleted = Column(Integer, default=0)
def
OK, cool. I'm in agreement with your explained storage/logic separation
below.
Cheers,
-jay
On 08/19/2013 03:12 AM, Robert Collins wrote:
On 19 August 2013 18:35, Jay Pipes jaypi...@gmail.com wrote:
Hi Jay,
When I started working around unique keys, I tried to use deleted_at
column. so answer about why we don't use deleted_at column you could read
in Devananda's comment on my patch https://review.openstack.org/#/c/16162/ .
Also I should mention that this is really huge change and it will
On 18/08/13 18:47 -0400, Jay Pipes wrote:
On 08/18/2013 06:28 PM, Joe Gordon wrote:
On Aug 18, 2013 3:58 PM, Jay Pipes jaypi...@gmail.com
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
Flavio,
Agreed. I'd also like to see other project migrated before pulling
oslo.db out from oslo-incubator
as I wrote before oslo.db code is used by: Nova, Neutron, Cinder, Ironic,
Ceilometer use oslo.db. And we have already patches to switch in Glance to
id. And we are woking in Keystone and
Hi,
1) Can I Expose
the host-aggregate as availability zone?
2) Is there anyway to make the Host Aggregate dynamically growing (with each VM
creation- add the host to host aggregate if its not already there)?
Thanks,
Sudheesh___
OpenStack-dev
Hi,
1) Can I Expose
the host-aggregate as availability zone?
2) Is there anyway to make the Host Aggregate dynamically growing (with each VM
creation- add the host to host aggregate if its not already there)?
Thanks,
Sudheesh___
OpenStack-dev
On Sun, Aug 18, 2013 at 07:02:04PM +0200, Matthieu Huin wrote:
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.
Thanks for this!!
On 19/08/13 04:33 -0700, Gary Kotton wrote:
So are you agree with next points?
1) In Havana focus on migrating in all projects to oslo.db code
[Gary Kotton] It is worth going for.
+1
2) in IceHouse create and move to oslo.db lib
[Gary Kotton] I am in favor of this pending the stability
Flavio,
So could you review please patches in Glance? =)
Best regards,
Boris Pavlovic
--
Mirantis Inc.
On Mon, Aug 19, 2013 at 4:33 PM, Flavio Percoco fla...@redhat.com wrote:
On 19/08/13 04:33 -0700, Gary Kotton wrote:
So are you agree with next points?
1) In Havana focus on migrating
On 19/08/13 16:45 +0400, Boris Pavlovic wrote:
Flavio,
So could you review please patches in Glance? =)
Yes, I'll sync with Mark and other folks to make sure all doubts are
cleared.
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
On 08/18/2013 04:04 PM, Jay Pipes wrote:
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
On 08/19/2013 09:40 AM, Julien Danjou wrote:
On Mon, Aug 19 2013, Sandy Walsh wrote:
On 08/19/2013 05:08 AM, Julien Danjou wrote:
On Sun, Aug 18 2013, Jay Pipes wrote:
I'm proposing that in these cases, a *new* resource would be added to the
resource table (and its ID inserted in meter)
On Mon, Aug 19, 2013 at 6:06 AM, Steven Hardy sha...@redhat.com wrote:
On Sun, Aug 18, 2013 at 07:02:04PM +0200, Matthieu Huin wrote:
Hi Steve,
It might be a bit late for this, but here's a script I wrote when
experimenting with trusts:
On Fri, Aug 16, 2013 at 2:51 PM, Miller, Mark M (EB SW Cloud - RD -
Corvallis) mark.m.mil...@hp.com wrote:
Is OpenStack supported on CentOS running Python 2.6?
Oh, I forgot to mention, keystone's py2.6 support seems to currently be
broken because of this bug:
In this thread about code review:
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013701.html
I mentioned that I thought there were too many blueprints created without
sufficient supporting design information and were being used for tickbox
process compliance only. I based this
On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Zane Bitter's message of 2013-08-16 09:36:23 -0700:
On 16/08/13 00:50, Christopher Armstrong wrote:
*Introduction and Requirements*
So there's kind of a perfect storm happening around autoscaling in
Daniel P. Berrange wrote:
In this thread about code review:
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013701.html
I mentioned that I thought there were too many blueprints created without
sufficient supporting design information and were being used for tickbox
On 08/16/2013 04:58 PM, Doug Hellmann wrote:
The notification messages don't translate 1:1 to database records. Even
if the notification payload includes multiple resources, we will store
those as multiple individual records so we can query against them. So it
seems like sending individual
On Wed, Aug 14, 2013 at 7:12 PM, Robert Collins
robe...@robertcollins.netwrote:
Note specifically the citation of 200-400 lines as the knee of the review
effectiveness curve: that's lower than I thought - I thought 200 was
clearly fine - but no.
This is really interesting. I wish they would
For what it's worth... this doesn't seem too bad to me...
I was planning on using this part of the vSphere API:
*
https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.CloneSpec.html
...to accomplish the clone part of the BP. The API contains a spec section
where
All I'm saying is that we should be careful not to swap one set of
problems for another.
My 2 cents: I am in agreement with Jay. I am leery of NoSQL being a
direct sub in and I fear that this effort can be adding a large workload
for little benefit.
A somewhat related post:
Hi Matt,
it is not an accident that savanna-extra has no tarballs at tarballs.o.o,
because this repo is used for storing some date that is only needed for some
stuff like building images for vanilla plugin, storing Swift support patch for
Hadoop and etc. So, it looks like that we should not
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting tomorrow, Tuesday August 20th, at 19:00 UTC in
#openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone interested in
Mark,
But for a variety of reasons, I do not consider the general thrust of use
oslo db code to be approved. Instead, lets continue to consider features
from olso db on a case by case basis, and see what the right resolution is
in each case.
Absolutely agree with this point (e.g. we removed
Greetings,
Some OpenStack programs have started a nice trend of getting together in
the middle of the development cycle. These meetups can serve a number
of useful purposes: community building, ramping up new contributors,
tackling hard problems by getting together in the same room, and more.
I
Hi folks
I would like to discuss whether supporting OpenSwan or StrongSwan or Both for
ipsec driver?
We choose StrongSwan because of the community is active and plenty of docs.
However It looks like RHEL is only supporting OpenSwan.
so we should choose
(A) Support StrongSwan
(B) Support
As I said during the meeting, I am happy to support both as long as the
code churn is reasonably contained and the chances of strongswan support
introducing bugs into openswan driver are negligible.
Openswan should be the default solution, in muy opinion.
Salvatore
On 20 August 2013 00:15,
Hi Salvatore
Thank you for your comment.
I'm adding OpenSwan support as additional driver, so it is safe for strongswan.
Best
Nachi
2013/8/19 Salvatore Orlando sorla...@nicira.com:
As I said during the meeting, I am happy to support both as long as the code
churn is reasonably contained and
So, in what can only be described as extremely embarrassing and wow, I
thought I knew how to use a computer: netifaces appears to work ok under
PyPy! I could have sworn I'd tested it, but apparently not. So, this is no
longer a high priority item for me to get swift on pypy (in fact, +/-
eventlet
Hi folks,
I'd like to continue the discussion about this.
I think we have the following questions to answer:
1) What should be the workflow of provider removal for the admin?
2) Do we allow 'update' operation on provider attribute?
3) Do we allow removing provider for users?
My take on these:
Just a related question,
Oslo 'incubator' db code I think depends on eventlet. This means any code that
uses the oslo.db code could/would(?) be dependent on eventlet.
Will there be some refactoring there to not require it (useful for projects
that are trying to move away from eventlet).
On Tue, Aug 20, 2013 at 5:14 AM, Jay Buffington m...@jaybuff.com wrote:
This is really interesting. I wish they would have explicitly defined
lines of code. Is that git show |wc -l? Just the new lines which
were added? The sum of the lines changed, removed and added? You can
get vastly
On 2013年08月17日 00:14, Vishvananda Ishaya wrote:
On Aug 15, 2013, at 5:58 PM, Melanie Witt melw...@yahoo-inc.com wrote:
On Aug 15, 2013, at 1:13 PM, Joe Gordon wrote:
+1 from me as long as this wouldn't change anything for the EC2 API's security
groups support, which I assume it won't.
Greetings stackers!
August 22nd is fast approaching. Here's the reviews in flight. We have 5 ready
for a core reviewer to take a look. One needing some attention from someone who
knows VMware's APIs and 8 that are in need of work/discussion. I noticed that
there was some issues with Jenkins
On 08/19/13 20:34, Joshua Harlow wrote:
Just a related question,
Oslo 'incubator' db code I think depends on eventlet. This means any code
that uses the oslo.db code could/would(?) be dependent on eventlet.
Will there be some refactoring there to not require it (useful for projects
42 matches
Mail list logo
