On Jul 13, 2013, at 8:28 AM, Sean Dague <s...@dague.net> wrote:

> Like I said, as long as someone is going to work on it, I'm happy. :) I just 
> don't want this to be an enable the tests and hope magically fairies come to 
> fix them issue. That's what we did on full neutron tests, and it's been 
> bouncing around like that for a while.
> 
> We are planning on disabling the devstack exercises, it wasn't so much that, 
> it's that it looks like there is fundamental lack of functioning nova on 
> devstack for cells right now. The security groups stack trace is just a side 
> effect of cells falling over in a really low level way (this is what's before 
> and after the trace).
> 
> 2013-07-13 00:12:18.605 ERROR nova.cells.scheduler 
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate 
> with cell 'child'
> ....
> 2013-07-13 00:12:18.606 ERROR nova.cells.scheduler 
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate 
> with any cells
> 

Did you dig these out manually somehow?   It looks like that unfortunately 
there's no screen-n-cells.txt saved in the gate, which would be extremely 
useful. :)  It looks like all errors must be limited to that service right now… 
makes me wonder if the devstack needs tweaked now for cells.

In fact, I *might* know the problem.   Some cells config options were 
deprecated, and it appears that backwards compatibility was lost.  I ran into 
this myself, and I took a stab at fixing it (I was unable to reproduce it in 
tests, but it certainly showed up in one of our environments).

We should probably commit a fix to devstack to use the new config options no 
matter what:

1) Remove the usage of compute_api_class CONF option
2) Where compute_api_class was set to the ComputeCells class in the API cell, 
instead use this config:

[cells]
cell_type=api

3) In a child cell where you did not override compute_api_class, use this:
[cells]
cell_type=compute

Maybe someone could try committing that fix to devstack for me while I'm 
traveling? :)   I wonder if that'll get us a little further along...

- Chris



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to