dtroyer at gmail
Aug 9, 2012, 1:43 PM
Post #4 of 4
On Thu, Aug 9, 2012 at 2:33 PM, Thomas Gall <thomasagall [at] gmail> wrote:
> ====================================================================> FAILED boot_from_volume
> FAILED euca
> FAILED floating_ips
> FAILED volumes
These all spawn instances so there's the first thing to check...
> I'm new so certainly possible I've missed an email/bug that documents this.
> I did also try on f17 but the results were exactly the same. Not that it
> should matter but I have devstack running inside of a kvm partition. Nothing
> obvious seems amiss.
Yes, running inside a VM does make a difference, mostly in the default
timeouts. Also, how much ram does your devstack VM have? You'll need
1G minimum to run everything unless you have Swift enabled, then at
> localrc has nothing in it but the settings for MYSQL_PASSWORD,
> RABBIT_PASSWORD, SERVICE_TOKEN, SERVICE_PASSWORD, ADMIN_PASSWORD
I usually set the following timeouts running in a Rax VM (VirtualBox
often needs a bit longer for me):
If you immediately do the following:
after the exercise failure, what to you see? If there is one running
VM and maybe one or more in error state, you may be up agains the
timeouts or possibly don't have enough RAM in your devstack vm.
Try running just one exercise at a time to debug this,
exercises/floating_ips.sh is what I usually use.
Another trick I use to reduce the RAM required for the VMs is to
create an m1.miro flavor and set in localrc:
The exercises will honor that in selecting the VM to create when they
run. The commands to do that are in samples/local.sh in the devstack
dtroyer [at] gmail
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp