[openstack-dev] cells checks on patches

Sean Dague sean at dague.net
Sat Jul 27 13:10:02 UTC 2013


Comments in the review as well. There are a couple of tabs that need
to be cleaned up, then I'm good. What's the long term outlook for
floating-ips, security groups, and aggregates for cells?

On Fri, Jul 26, 2013 at 9:22 PM, Chris Behrens <cbehrens at codestud.com> wrote:
> I have just put up a review here:
>
> https://review.openstack.org/#/c/38897/
>
> which should address the exercise.sh issues when n-cell is enabled.
> Hopefully this works in the gate like it does for me locally.  Then we can
> move on to looking at tempest.
>
> - Chris
>
>
> On Jul 15, 2013, at 6:13 AM, Andrew Laski <andrew.laski at rackspace.com>
> wrote:
>
> I will also be working to help get cells passing tests.  I just setup a
> blueprint on the Nova side for this,
> https://blueprints.launchpad.net/nova/+spec/cells-gating.
>
> On 07/13/13 at 05:00pm, Chris Behrens wrote:
>
> I can make a commitment to help getting cells passing.  Basically, I'd like
> to do whatever I can to make sure we can have a useful gate on cells.
> Unfortunately I'm going to be mostly offline for the next 10 days or so,
> however. :)
>
> I thought there was a sec group patch up for cells, but I've not fully
> reviewed it.
>
> The generic "cannot communicate with cell 'child'" almost sounds like some
> other basic issue.... I'll see if I can take a peak during my layovers
> tonight.
>
> On Jul 13, 2013, at 8:28 AM, Sean Dague <sean at dague.net> wrote:
>
> On 07/13/2013 10:50 AM, Dan Smith wrote:
>
> Currently cells can even get past devstack exercises, which
> are very
> minor sanity checks for the environment (nothing tricky).
>
>
> I thought that the plan was to deprecate the devstack exercises and
> just use tempest. Is that not the case? I'd bet that the devstack
> exercises are just not even on anyone's radar. Since the excellent work
> you QA folks did to harden those tests before grizzly, I expect most
> people take them for granted now :)
>
> Digging into the logs just a bit, I see what looks like early failures
> related to missing security group issues in the cells manager log. I
> know there are some specific requirements in how things have to be set
> up for cells, so I think it's likely that we'll need to do some
> tweaking of configs to get all of this right.
>
> We enabled the test knowing that it wasn't going to pass for a while,
> and it's only been running for less than 24 hours. In the same way that
> the grenade job had (until recently) been failing on everything, the
> point of enabling the cells test now is so that we can start iterating
> on fixes so that we can hopefully have some amount of regular test
> coverage before havana.
>
>
> 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
>
> Again, mostly I want to know that we've got a blueprint or bug that's high
> priority and someone's working on it. It did take a while to get grenade
> there (we're 2 bugs away from being able to do it repeatably in the gate),
> but during that time we did have people working on it. It just takes a while
> to get to the bottom of these issues some times, so I want people to have a
> realistic expectation on how quickly we'll go from running upstream to
> gating.
>
>   -Sean
>
> --
> Sean Dague
> http://dague.net
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list