Hi team,
I want to discuss benefits of using host networking [1] for docker
containers, on master node.
This feature was added in docker 0.11 and basicly means - reuse host
networking stack, without
creating separate namespace for each container.
In my opinion it will result in much more stable
The root cause for the issue was the fact that our devstack VMs were still
running libvirt 0.9.8 and we missed the commit where libvirt 0.9.11 was
forced as a minimum requirement.
This has been fixed for a while now. However, I made a mistake and as a
result some patches have received a -1 from
We seem to be unable to address some key issues in the software we
produce, and part of it is due to strategic contributors (and core
reviewers) being overwhelmed just trying to stay afloat of what's
happening. For such projects, is it time for a pause ? Is it time to
define key cycle
Eoghan,
Nice work on this. I think that first of all this job should be run on
every patch for some period of time (not only in experimental pipe)
By the way, If you would like we can help from Rally side.
We are running benchmarks on every patch in it's gates. Ceilometer is fully
turned on in
On Aug 9, 2014 4:22 AM, Eoghan Glynn egl...@redhat.com wrote:
Hi Folks,
Dina Belova has recently landed some infra patches[1,2] to create
an experimental mongodb-based Tempest job. This effectively just
overrides the ceilometer storage backend config so that mongodb
is used instead of
Hi Folks,
Dina Belova has recently landed some infra patches[1,2] to create
an experimental mongodb-based Tempest job. This effectively just
overrides the ceilometer storage backend config so that mongodb
is used instead of sql-alchemy. The new job has been running
happily for a
Eoghan,
Nice work on this. I think that first of all this job should be run on every
patch for some period of time (not only in experimental pipe)
By the way, If you would like we can help from Rally side.
We are running benchmarks on every patch in it's gates. Ceilometer is fully
+2 from me,
More mongodb adoption (as stated) when it's questionable legally doesn't seem
like a good long term strategy (I know it will/does impact yahoo adopting or
using ceilometer...). Is this another one of those tactical changes that we
keep on making that ends up being yet another piece
+2 from me,
More mongodb adoption (as stated) when it's questionable legally doesn't seem
like a good long term strategy (I know it will/does impact yahoo adopting or
using ceilometer...). Is this another one of those tactical changes that we
keep on making that ends up being yet another
Agreed, testing options is good; and should likely be disjoint from the legal
questions around mongodb...
Although if there is really only one viable scalable option and that option
has legal usage questions surrounding it then it makes me wonder how much we
are kidding ourselves on there
On Fri, Aug 8, 2014 at 1:31 AM, Nikola Đipanov ndipa...@redhat.com wrote:
On 08/08/2014 12:12 AM, Stefano Maffulli wrote:
On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
My point was simply that we don't have direct control over the
contributors' activities
This is not correct and I've
Agreed, testing options is good; and should likely be disjoint from the legal
questions around mongodb...
Although if there is really only one viable scalable option and that option
has legal usage questions surrounding it then it makes me wonder how much we
are kidding ourselves on
On 2014-08-08 09:43:54 -0700 (-0700), Devananda van der Veen wrote:
[...]
this sounds like it will also solve the current problem when a
core reviewer has gone on vacation after blocking something for
procedural reasons.
I don't really think so, unless I'm misunderstanding which vacation
+1 to what john said,
I would also like to wait and see on this... I'd rather be honest with
ourselves, and to contributors new and old, and admit core reviewers are air
traffic controllers (directing the project vs reviewing changes, two very
different things IMHO) and reflecting that in what
On 2014-08-08 09:06:29 -0400 (-0400), Russell Bryant wrote:
[...]
We've seen several times that building and maintaining 3rd party
CI is a *lot* of work.
Building and maintaining *any* CI is a *lot* of work, not the least
of which is the official OpenStack project CI (I believe Monty
mentioned
Paul, does this friend of a friend have a reproduceable test script for
this?
Thanks!
-jay
On 08/08/2014 04:42 PM, Kevin Benton wrote:
If this is true, I think the issue is not on Neutron side but the Nova
side.
Neutron just receives and handles individual port requests. It has no
notion of
On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote:
Paul, does this friend of a friend have a reproduceable test script for
this?
Thanks!
-jay
We would also need to know the OpenStack release where this issue manifest
itself. A number of bugs have been raised in the past around
I have reported a bug as tempest volume-type test failed for hp_msa_fc
driver in tempest
project.
Bug Id is Bug #1353850
My Tempest tests are failed on cinder driver.
No one till responded to my bug.
I am new in this area.
Please help me to solve this.
Regards
Nikesh
On Sat, Aug 9, 2014 at 1:58 PM, Nikesh Kumar Mahalka
nikeshmaha...@vedams.com wrote:
I have reported a bug as tempest volume-type test failed for hp_msa_fc
driver in tempest
project.
Bug Id is Bug #1353850
My Tempest tests are failed on cinder driver.
No one till responded to my bug.
I
So I've done some work on improving the code on the current pending
reviews. And would like to get peoples' opinions on whether I should
add antoher patch set to those reviews, or add the changes as as another
review dependent on the pending ones.
To be clear, no matter what the first review in
I think you should update the current reviews (new patch set, not additional
review.)
Doug
On Aug 9, 2014, at 3:34 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
So I've done some work on improving the code on the current pending
reviews. And would like to get peoples' opinions
Hi Paul, as I know, nova can guarante the ordering of vNICS, can you provide
the reproduceable test script for this, I am glad to test it
At 2014-08-10 01:16:16, Jay Pipes jaypi...@gmail.com wrote:
Paul, does this friend of a friend have a reproduceable test script for
this?
Thanks!
On 08/08/2014 11:54 PM, Ryan Hsu wrote:
Thanks very much Anita. According to the Gerrit documentation [1], there is a
command to set the http password for a given account. It does require
administrator privileges though.
set-account [--full-name FULLNAME] [--active|--inactive] \
Sounds good, I’ll be there!
Ryan
On Aug 8, 2014, at 11:04 PM, Anita Kuno ante...@anteaya.info wrote:
On 08/08/2014 11:54 PM, Ryan Hsu wrote:
Thanks very much Anita. According to the Gerrit documentation [1], there is
a command to set the http password for a given account. It does require
On 08/04/2014 08:42 AM, Erlon Cruz wrote:
On 07/22/2014 05:15 PM, Wilfredo Ronsini wrote:
I work in the Flextronics Institute of Technology and I am in the process
of setting an OpenStack CI server.
Please, create a Gerrit user account.
Preferred username: wronsini
Best regards,
You need to be an admin to run this script.
On Fri, Aug 08, 2014 at 04:15:17PM -0400, Parisa Heidari wrote:
Hi Steve,
Thanks for your help. I tried either files but in both cases I get the same
error. I copy the output below. It seems that the OS variables are exported
properly. Any help is
I have reported a bug as tempest volume-type test failed for hp_msa_fc
driver in tempest
project.
Bug Id is Bug #1353850
My Tempest tests are failed on cinder driver.
No one till responded to my bug.
I am new in this area.
Please help me to solve this.
Regards
Nikesh
27 matches
Mail list logo
