Ajay,
to be more precise, we also already had a feature request
https://github.com/stackforge/rally/blob/master/doc/feature_request/multi_scenarios_load_gen.rst
for
implementing load generation from multiple scenarios, which seems to be
exactly what you proposed. So we are working on this.
Best
On 8/29/2014 1:53 PM, Kyle Mestery wrote:
On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 7/29/2014 4:12 PM, Kyle Mestery wrote:
On Tue, Jul 29, 2014 at 3:50 PM, Nader Lahouti nader.laho...@gmail.com
wrote:
Hi Kyle,
I have a BP listed in
On Aug 22, 2014 12:48 AM, Steve Kowalik ste...@wedontsleep.org wrote:
On 22/08/14 17:35, Chris Jones wrote:
Hi
When register-nodes blows up, is the error we get from Ironic
sufficiently unique that we can just consume it and move on?
You should get a clear error when attempting to add a
Michael Still wrote:
I've built this handy dandy list of granted FFEs, because searching
email to find out what is approved is horrible. It would be good if
people with approved FFEs could check their thing is listed here:
https://etherpad.openstack.org/p/juno-nova-approved-ffes
It
Woops, meant to respond to this in the email I just sent...
On Aug 21, 2014 11:35 PM, Steve Kowalik ste...@wedontsleep.org wrote:
For other drivers, we think that the pm_address for each machine
will be unique. Would it be possible add some advice to that effect to
Ironic's driver API?
In that precise case, given how early it is in the freeze, I think
giving a quick heads-up to the -i18n team/list should be enough :) Also
/adding/ a string is not as disruptive to their work as modifying a
potentially-already-translated one.
Joe Cropper wrote:
+1 to what Jay said.
I’m not
Mykola, thanks for update!
Few additional notes on this. For now, we have to inject two patches to
make it work.
The first patch is a simple bugfix for the Coraid driver itself:
https://review.openstack.org/#/c/119022/
The second one is for Tempest to allow specification of custom volume type
Hi, Monty,
Thanks for bringing this topic up. I think the blueprint that Miguel
mentioned will address the issue you're sufffering from, but maybe
there are not many people interested in this feature, so
unfortunately, the bp will not be landed in Juno release. But I will
continue the bp when the
Good discussion.
Based on this I think we should get started on the stackforge right away.
Sumit - It would be great if you get started on the StackForge soon. We
have a few changes that needs to be submitted and have been holding up.
On Fri, Sep 5, 2014 at 8:08 AM, Mohammad Banikazemi
Hi Michael,
I see that ephemeral storage encryption is not on the list of granted FFEs but
I sent an email to John Garbutt yesterday listing
the 3 core sponsors for the FFE. Why was the FFE denied?
Dan
From: Michael Still mi...@stillhq.com
Sent: Friday,
Thanks, ttx.
If there’s anyone that can do a final review on
https://review.openstack.org/#/c/118535/ — would be much appreciated and I’m
happy to llet the i18n folks know once it merges.
- Joe
On Sep 6, 2014, at 9:36 AM, Thierry Carrez thie...@openstack.org wrote:
In that precise case,
While it's good that somebody is addressing this specific issue, perhaps
punctual solutions - eg: hey I have a patch for that, are not
addressing the general issues, which is that Neutron has very granular
primitives that force users to do multiple API requests for operations they
regard as
Thierry,
Thanks! I agree.
Jay
On Sep 6, 2014 9:37 AM, Thierry Carrez thie...@openstack.org wrote:
In that precise case, given how early it is in the freeze, I think
giving a quick heads-up to the -i18n team/list should be enough :) Also
/adding/ a string is not as disruptive to their work
That's something I'll work on today.
Michael
On Sun, Sep 7, 2014 at 12:32 AM, Thierry Carrez thie...@openstack.org wrote:
Michael Still wrote:
I've built this handy dandy list of granted FFEs, because searching
email to find out what is approved is horrible. It would be good if
people with
The process for requesting a FFE is to email openstack-dev and for the
core sponsors to signup there. I've obviously missed the email
thread... What is the subject line?
Michael
On Sun, Sep 7, 2014 at 3:03 AM, Genin, Daniel I.
daniel.ge...@jhuapl.edu wrote:
Hi Michael,
I see that ephemeral
Not sure if https://review.openstack.org/#/c/118619/ is necessary.
See if this solves your issue [1], simple update to your devstack
localrc/local.conf to create the type keys. It is merged to master.
Otherwise, consider creating a cinder backend file[1].
Ramy
[1]
There was a review once that tried to move the evzookeeper to using kazoo,
perhaps that can get reprioritzed??
https://review.openstack.org/#/c/28951/
Sent from my really tiny device...
On Sep 5, 2014, at 6:36 AM, Sean Dague s...@dague.net wrote:
While reviewing this zookeeper service
On Sat, Sep 6, 2014 at 8:43 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 8/29/2014 1:53 PM, Kyle Mestery wrote:
On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 7/29/2014 4:12 PM, Kyle Mestery wrote:
On Tue, Jul 29, 2014 at 3:50 PM, Nader
Hi Steven,
Thanks for taking the time to lay out the components clearly. I think we are
pretty much on the same page ☺
Driver vs, Driver-less
I strongly believe that REST is a cleaner interface/integration point – but if
even Brandon believes that drivers are the better approach (having
Hi All,
I have openstack installed on RHEL6.5 using RDO Quickstart. Everything is now
working except for a weird volume attachment issue.
I have a program which launches instance and then starts two threads. One to
create a volume (10GB) from snapshot and attach to server, the other to create
Hi All,
Deleting a volume is very slow. Even a 1GB volume takes a long time (3-5
minutes).
I updated nova.conf and cinder.conf to set volume_clear to none and
volume_clear_size to 10.
I ensured that the services were restarted. Even after machine reboot the
volume deletion is not fast.
Is
On Sep 5, 2014, at 11:13 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Doug Hellmann [d...@doughellmann.com]
The zmq driver in oslo.messaging, used for internal communication
between OpenStack services, has been without a maintainer for a
significant period of time. It isn’t
The team has been focused on library graduation this cycle, so some bugs have
not received the attention we would like. Now that we’re in the feature-freeze
period, some reviewer resources should be freed up. I will add those patches to
the priority list to see what we can do about them.
Doug
On Sep 5, 2014, at 5:02 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
What about just using the kombu transport instead?
https://github.com/celery/kombu/blob/master/kombu/transport/zmq.py
Then people have a way to use oslo.messaging (the rabbit impl just uses
kombu) with zmq without
From: Doug Hellmann [d...@doughellmann.com]
On Sep 5, 2014, at 11:13 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Doug Hellmann [d...@doughellmann.com]
The zmq driver in oslo.messaging, used for internal communication
between OpenStack services, has been without a maintainer for a
On Sep 6, 2014, at 11:00 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Doug Hellmann [d...@doughellmann.com]
On Sep 5, 2014, at 11:13 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Doug Hellmann [d...@doughellmann.com]
The zmq driver in oslo.messaging, used for internal
We couldn't get the zmq driver to work so we stuck with our patched rabbit
version.
On 2014-09-06 10:15 AM, Doug Hellmann d...@doughellmann.com wrote:
On Sep 6, 2014, at 11:00 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
From: Doug Hellmann [d...@doughellmann.com]
On Sep 5, 2014, at
Hi,
I am trying to setup openstack with 3 node setup .
i am following
OPENSTACK INSTALLATION GUIDE FOR UBUNTU 12.04/14.04 (LTS) - ICEHOUSE
http://docs.openstack.org/icehouse/install-guide/install/apt/content/index.html
http://docs.openstack.org/icehouse/install-guide/install/apt/content/
the
28 matches
Mail list logo