Highlights of the week
OpenStack Events at OSCON Discounted Passes
http://www.openstack.org/blog/2012/06/openstack-events-at-oscon-discounted-passes/
We have quite a few activities planned for OSCON to celebrate
OpenStack's second birthday. Kicking off with the first
On 06/28/2012 11:58 PM, Monty Taylor wrote:
On 06/28/2012 01:49 PM, Dan Prince wrote:
- Original Message -
From: Monty Taylor mord...@inaugust.com To:
openstack@lists.launchpad.net Sent: Thursday, June 28, 2012
11:13:28 AM Subject: Re: [Openstack] Jenkins vs SmokeStack tests
Gerrit
On Fri, Jun 29, 2012 at 5:19 AM, Devin Carlen de...@openstack.org wrote:
On Jun 28, 2012, at 9:01 AM, Jay Pipes wrote:
On 06/27/2012 06:51 PM, Doug Davis wrote:
Consider the creation of a Job type of entity that will be returned
from the original call - probably a 202. Then the client can
Hi,
I am a colleague of Bram working with him on these same systems.
We are now experiencing other issues related to networking on our nodes:
- we gave openstack eth0 as the vlan interface
- eth0 en eth1 are still slaves in a bond0 (mode 6)
== we are seeing a big number of dropped packets on
Vaze, Mandar wrote:
I particularly hate the single-line Fixes bug 1234566-type commit messages.
I assume your concern was regarding commits where Fixes bug 1234566 is the
first and ONLY line.
Yes, that is the particularly offensive form :)
Plus there is restriction on how long the first
On Fri, Jun 29, 2012 at 04:57:06AM +, Vaze, Mandar wrote:
I particularly hate the single-line Fixes bug 1234566-type commit
messages.
I assume your concern was regarding commits where Fixes bug 1234566 is the
first and ONLY line.
Fixes bug 1234566 comes from Wiki.
Plus there
At the very least it is always possible to describe what area of the code is
being changed, so that you alert the reviewers you are familiar with that
area.
Yes, Makes sense.
-Mandar
__
Disclaimer:This email and any
Note that I do distinguish between a 'real' async op (where you
really return little more than a 202) and one that returns a
skeleton of the resource being created - like instance.create() does
now.
So the latter approach at least provides a way to poll on the resource
status, so as to
Right - examining the current state isn't a good way to determine what
happened with one particular request. This is exactly one of the reasons
some providers create Jobs for all actions. Checking the resource later
to see why something bad happened is fragile since other opertaons might
Hi-
I'm new this community. And in need of help..
I have gone through Tilera support in the web documentation.
Can any one guide me on How to enable NON x_86 arch. support in Openstack
like enabling Tilera board support or some other Hardware architecture
support in an already installed
Hello,
I'm sorry to restart the topic (
https://lists.launchpad.net/openstack/msg13621.html), but
i accidentally deleted the message in my inbox :S.
I'm still having the same problem, each time i add import libvirt to the
file diangostics.py (https://review.openstack.org/#/c/8839/) the entire
tl;dr: Ceilometer should ignore resource metadata when computing sums or
maximum values for counters through the API.
One of the things we discussed early during the design meetings was the
need to track metadata along with resources so providers could use the
metadata to determine the rate to
Hello everyone,
Once upon a time, each OpenStack client library was independent and had
its own project in Launchpad. Then when Core projects came to rely on
them, we pulled them in as official projects but since we didn't want
to create Core projects for each of them, we considered them separate
On Fri, Jun 29 2012, Doug Hellmann wrote:
Thoughts?
Please correct me if I'm wrong.
What I understand is that you're saying that something like:
GET
v1/[SOURCES/SOURCE/]USERS/USER_ID/RESOURCES/RESOURCE_ID/METER/VOLUME
as defined in the current API draft, for a counter like instance CPU
One of the things that's really bugging me these days is transient
failures, such as the inability to download a package, causing a gate
job to fail. It seems to me that we can distinguish test failure from
environment build failure easily enough, and automatically retry in
the latter case. Is
Lately I've been noticing that some individual unit tests fail for
me, even though the overall test suite succeeds. So, for example:
$ /opt/stack/nova$ ./run_tests.sh
snip
OK (SKIP=5)
$ /opt/stack/nova$ ./run_tests.sh test_virt_drivers
AbstractDriverTestCase
test_add_to_aggregate
However, considering the unhappy-path for a second, is there a place
for surfacing some more context as to why the new instance unexpectedly
went into the ERROR state?
I assume the philosophy is that the API has validated the request as far and it
can, and returned any meaningful error
On Fri, 2012-06-29 at 10:34 -0500, Andrew Bogott wrote:
$ /opt/stack/nova$ ./run_tests.sh test_virt_drivers
AbstractDriverTestCase
test_add_to_aggregateERROR
0.02
test_agent_updateERROR
0.02
Leander,
As the error message indicates, it usually comes when the option is found in
more than one place.
Thanks,
Joseph
(w) 703-248-6160
(f) 703-812-3712
http://www.east.isi.edu/~jsuh
Information Sciences Institute
University of Southern California
3811 N. Fairfax Drive Suite 200
On 06/29/2012 04:06 AM, Alan Pevec wrote:
On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor mord...@inaugust.com wrote:
https://review.openstack.org/9109
Why is setuptools_git added in pip-requires, I thought that's for
run-time, not build-time dependencies?
Hey Alan!
We use pip-requires as
On Fri, Jun 29 2012, Doug Hellmann wrote:
We do have counters for RAM and CPU separate from instance. But the rate at
which the provider bills for those things may vary based on metadata. My
example may be bad because it uses 2 values we're measuring, one of which
also shows up in the
Should there be a separation of build-time setup.py and run-time setup.py??
I'm not sure if something like that is possible (maybe with a setuptools
variant, distribute or something similar??)
On 6/29/12 4:06 AM, Alan Pevec ape...@gmail.com wrote:
On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor
On Fri, Jun 29, 2012 at 1:19 PM, Julien Danjou jul...@danjou.info wrote:
On Fri, Jun 29 2012, Doug Hellmann wrote:
We do have counters for RAM and CPU separate from instance. But the rate
at
which the provider bills for those things may vary based on metadata. My
example may be bad
I have setup Essex on Centos 6.2 64 bit as per
http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL
I am using kvm/libvirt
I can create images fine with nova boot. If I choose the name to be
my.test.server, nova shows the name as local.test.server correctly,
however, when I ssh to
On 06/29/2012 10:30 AM, Joshua Harlow wrote:
Should there be a separation of build-time setup.py and run-time setup.py??
I’m not sure if something like that is possible (maybe with a setuptools
variant, distribute or something similar??)
Well, we use distribute already - but the problem
On 06/29/2012 04:25 AM, Huang Zhiteng wrote:
Sound like a performance issue. I think this symptom can be much
eased if we spend sometime fixing whatever bottleneck causing this
(slow AMQP, scheduler, or network)? Now that Nova API has got
multprocess enabled, we'd move to next bottleneck in
On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote:
We use pip-requires as part of building the virtualenvs. Once we start
using it, setuptools-git is pretty much required for running setup.py,
so many common actions in our workflow will require it.
It's a good question
An assumption is being made here that the user and cloud provider
are unrelated. But I think there are many projects under development
where a cloud-based service is being provided on top of an OpenStack
infrastructure. In that use case, the direct user of OpenStack APIs and
the cloud provider
On 06/29/2012 10:48 AM, Alan Pevec wrote:
On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote:
We use pip-requires as part of building the virtualenvs. Once we start
using it, setuptools-git is pretty much required for running setup.py,
so many common actions in our
On 06/29/2012 10:48 AM, Alan Pevec wrote:
On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote:
We use pip-requires as part of building the virtualenvs. Once we start
using it, setuptools-git is pretty much required for running setup.py,
so many common actions in our
Hello Trinath,
We're working on general bare-metal provisioning framework including several
architecture types such as x86-64/i386/ARM/tilera.
The target release for this is Folsom. That's not merged into upstream yet.
We're going to request whole review before August.
Please refer the
I have also verified this happens as well with debian wheezy and essex.
On Fri, 2012-06-29 at 13:42 -0400, Drewski wrote:
I have setup Essex on Centos 6.2 64 bit as per
http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL
I am using kvm/libvirt
I can create images fine with nova
On 6/27/12 8:40 AM, Daniel P. Berrange wrote:
On Wed, Jun 27, 2012 at 03:24:21PM +0200, Vincent Untz wrote:
Hi,
It'd be really great if we could first improve Gerrit to handle the
patch series workflow in a better way. Without such a change, pushing
patch series to Gerrit is really no fun for
On 06/21/2012 02:21 PM, Rick Jones wrote:
TSO and GRO can cover a multitude of path-length sins :)
That is one of the reasons netperf does more than just bulk transfer :)
When I was/am measuring scaling of an SMP node I would use
aggregate, burst-mode, single-byte netperf TCP_RR tests to
You don't really expect a client (think ec2-like-user) to analyze debug
info do you?
I really think we need a nice consistent way for people to see what's
going on with long-running operations. Debug info isn't that to me.
thanks
-Doug
__
On 06/29/2012 05:45 PM, Doug Davis wrote:
You don't really expect a client (think ec2-like-user) to analyze debug
info do you?
I really think we need a nice consistent way for people to see what's
going on with long-running operations. Debug info isn't that to me.
thanks
-Doug
Also, see:
True that's all useful info but I thought the original problem being
addressed was how the end-user could know what's going on for long-running
ops.
thanks
-Doug
__
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM
Highlights of the week
OpenStack Events at OSCON Discounted Passes
http://www.openstack.org/blog/2012/06/openstack-events-at-oscon-discounted-passes/
We have quite a few activities planned for OSCON to celebrate
OpenStack's second birthday. Kicking off with the first
There's only 1 rpc call unless you're running cactus or something. All
schedulers have a loop...not API.
min-count is unfortunately special cased right now to be a single call vs cast,
though. I was going to fix that real soon. Problem is scheduler creating the
DB records vs API in this
On 04/01/2012 11:15 AM, Lorin Hochstein wrote:
On Mar 29, 2012, at 12:40 PM, Daniel P. Berrange wrote:
On Wed, Mar 28, 2012 at 04:41:28PM -0400, Lorin Hochstein wrote:
All:
Given that I have a qcow2 image from somewhere (e.g., downloaded
it from a uec-images.ubuntu.com
Hey all,
I would like to setup a highly available service *inside* two KVM instances,
so I have created a security group to contain all required service ports,
so clients can connect to either VM and that works.
And both instances have their own designated IP address, provided by
nova itself.
Seems like you could use a floating ip for this. You can define a range for
internal floating ips by using a separate floating ip pool.
On Jun 29, 2012 7:06 PM, Christian Parpart tra...@gmail.com wrote:
Hey all,
I would like to setup a highly available service *inside* two KVM
instances,
so
On 6/29/12 10:57 AM, Kevin L. Mitchell wrote:
On Fri, 2012-06-29 at 10:34 -0500, Andrew Bogott wrote:
$ /opt/stack/nova$ ./run_tests.sh test_virt_drivers
AbstractDriverTestCase
test_add_to_aggregateERROR
0.02
test_agent_update
I'm running nova image-create for the first time, and on the compute
node I see:
qemu-img convert -f qcow2 -O qcow2 -s 98a8efe9ec114b489eb163c64661441a
/virt/pools/openstack_2/instance-0011/disk
/tmp/tmpH9KkUZ/98a8efe9ec114b489eb163c64661441a
I am concerned to see this operation
Title: quantal_folsom_nova_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/60/Project:quantal_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 07:28:33 -0400Build duration:2 min 49 secBuild cause:Started by user zulBuilt
at 20120629-0741Build needed 00:02:09, 20724k disc
Title: quantal_folsom_nova_trunk
General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/62/Project:quantal_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 08:18:20 -0400Build duration:6 min 28 secBuild cause:Started by user zulBuilt
Title: quantal_folsom_python-keystoneclient_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-keystoneclient_trunk/19/Project:quantal_folsom_python-keystoneclient_trunkDate of build:Fri, 29 Jun 2012 12:01:54 -0400Build duration:1 min 19
Title: quantal_folsom_python-novaclient_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-novaclient_trunk/14/Project:quantal_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 13:01:54 -0400Build duration:1 min 18 secBuild
Title: precise_folsom_python-novaclient_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_python-novaclient_trunk/15/Project:precise_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 13:01:54 -0400Build duration:1 min 22 secBuild
Title: quantal_folsom_python-novaclient_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-novaclient_trunk/15/Project:quantal_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 14:01:54 -0400Build duration:1 min 48 secBuild
at 20120629
at 20120629
at 20120629
Title: precise_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_quantum_trunk/15/Project:precise_folsom_quantum_trunkDate of build:Fri, 29 Jun 2012 20:32:50 -0400Build duration:2.6 secBuild cause:Started by an SCM changeBuilt
Title: quantal_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_quantum_trunk/16/Project:quantal_folsom_quantum_trunkDate of build:Fri, 29 Jun 2012 20:32:53 -0400Build duration:3.8 secBuild cause:Started by an SCM changeBuilt
at 20120629
at 20120629-2035Build needed 00:01:47, 20652k disc
58 matches
Mail list logo
