gt;
Sorry, this is a bit fastidious, but I think "nova live-migrate" is what
you mean here. "nova migrate", I think, is still a completely separate
code-path. live-migrate needs to talk to both the source and destination
nova-compute services to coordinate and confirm the
Hi Li,
The problem here is that db.service_get_by_compute_host() requires admin
context. [1] The live_migrate command needs to check that both hosts have a
running nova-compute service before it begins migration. Perhaps the
live_migrate task is passing the incorrect context in for this database
q
rs: the script that generated
etc/cinder/cinder.conf.sample in the 2013.2.3 release did not correctly
place configuration options under subsections.
I have filed a bug:
https://bugs.launchpad.net/cinder/+bug/1316684
On Fri, May 2, 2014 at 7:01 PM, Scott Devoid wrote:
> Hi all,
>
> I a
Hi all,
I am having trouble deploying a second cinder-volume service on our Havana
system (2013.2.3).
$ cinder service-list
+--+-+--+-+---++
| Binary | Host | Zone | Status | State | Updated_at
|
+---
Yup, this is a big deal for us. I can't realistically deploy Havana to my
users until this is resolved.
Note that my bug reports also cover a number of other undesirable behaviors
on the part of glance(-client).
- No checking of the "owner" field against keystone.
- Listing images does not query
Which driver are you using?
For OVS and Linux Bridge, there was decent documentation (including
diagrams) in the Grizzly-era Networking Administration Guide, the "Under
the Hood" section:
http://docs.openstack.org/grizzly/openstack-network/admin/content/under_the_hood_openvswitch.html
That guide
The TL;DR - We ran into problems with permissions for users within the same
tenant. With the current access controls it is impossible to fix this
without isolating each user in a personal project. Can we fix the
policy.json grammar to give us the access controls we want, or am I stupid
and missing
