[rdo-list] [TripleO] Newton large baremetal deployment issues

Michele Baldessari michele at acksyn.org
Wed Nov 16 16:42:51 UTC 2016


Hi Charles,

On Tue, Nov 15, 2016 at 10:39:19PM +0000, Charles Short wrote:
> So I have finally tried OSP9 and here are the results -
> 
> 3 Controllers 40 compute - 1 hours 20 mins to deploy.
> 
> This is much more the sort of deployment time I was expecting :)
> 
> I then tried TripleO Newton Stable again with  3 Controllers 40 Compute -
> 
> 4 hours and counting.....
> 
> The two deployment scripts (for OSP9 and TripleO Newton) were pretty much
> identical (allowing for any changes between releases)
> 
> During the OSP9 deployment I could use nova list to list the nodes. The
> Undercloud API access was in general very responsive.
> 
> During the TripleO Newton deployment 'nova list' hangs -
> ERROR (ClientException): The server has either erred or is incapable of
> performing the requested operation. (HTTP 500)
> Undercloud API access was very sluggish.
> I noticed Keystone was stuck at 140% for most of the deployment (albeit
> multi threaded) which is not the case for OSP9.
> 
> I know it is hard to compare two releases, but the difference is enormous.
> I will stick with OSP9 for now as this for me works properly out of the box
> for  large deployments.

May I ask what version of python-oslo-messaging you have on Newton?

The reason I ask, is that Eck fixed a pretty serious epoll() issue which
caused deploys to fail with newton on weaker hardware (which would work
in mitaka). The change I mention is this one:
https://review.openstack.org/#/c/394963/

It would be great to confirm or not if the python-oslo-messaging package
you are using has this change included.

Thanks,
Michele
-- 
Michele Baldessari            <michele at acksyn.org>
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D




More information about the rdo-list mailing list