[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 dev
mailing list