On 03/05/2014 07:24 AM, git harry wrote:
Hi,
https://blueprints.launchpad.net/cinder/+spec/cinder-rbd-driver-qos
I've been looking at this blueprint with a view to contributing on it, assuming
I can take it. I am unclear as to whether or not it is still valid. I can see
that it was
On 03/12/2014 04:54 PM, Matt Riedemann wrote:
On 3/12/2014 6:32 PM, Dan Smith wrote:
I'm confused as to why we arrived at the decision to revert the commits
since Jay's patch was accepted. I'd like some details about this
decision, and what new steps we need to take to get this back in for
On 03/13/2014 12:48 PM, Russell Bryant wrote:
On 03/13/2014 03:04 PM, Josh Durgin wrote:
These reverts are still confusing me. The use of glance's v2 api
is very limited and easy to protect from errors.
These patches use the v2 glance api for exactly one call - to get
image locations. This has
We're having an unconference session at the OpenStack design summit
on Friday at 2:20pm.
If you're interested in Ceph integration with OpenStack, please join us
to discuss future development.
Josh
___
OpenStack-dev mailing list
On 10/10/2014 08:44 PM, John Griffith wrote:
Hi,
So I've been beating on this for a good part of the day and I'm not
having much luck so I thought I'd ask on the ML if anybody has had any
success with the following.
We have some applications that have been migrated off of our physical
machines
On 09/18/2013 07:14 AM, Thierry Carrez wrote:
Mike Perez wrote:
Currently in Havana development, RBD as ephemeral storage has serious
stability
and performance issues that makes the Ceph cluster a bottleneck for using an
image as a source.
[...]
This comes up a bit late, and the current RC
Hey folks, thanks for filing a bug for this:
https://bugs.launchpad.net/cinder/+bug/1452641
Nova stores the volume connection info in its db, so updating that
would be a workaround to allow restart/migration of vms to work.
Otherwise running vms shouldn't be affected, since they'll notice any
On 05/08/2015 12:41 AM, Arne Wiebalck wrote:
Hi Josh,
In our case adding the monitor hostnames (alias) would have made only a
slight difference:
as we moved the servers to another cluster, the client received an
authorisation failure rather
than a connection failure and did not try to fail over
mon’s which have not changed.
Thanks, it all makes sense now.
Josh
On 12 May 2015, at 01:46, Josh Durgin jdur...@redhat.com wrote:
On 05/08/2015 12:41 AM, Arne Wiebalck wrote:
Hi Josh,
In our case adding the monitor hostnames (alias) would have made only a
slight difference:
as we moved