Cross posting from Openstack-dev because Tom's unable to post to this
list yet. Manila operators, please note the session at the Forum next
week.
Thanks,
Goutham
-- Forwarded message --
From: Tom Barron
Date: Thu, May 17, 2018 at 10:57 AM
Subject:
CERN has upgraded to Cells v2 and is doing performance testing of the
scheduler and were reporting some things today which got us back to this
bug [1]. So I've starting pushing some patches related to this but also
related to an older blueprint I created [2]. In summary, we do quite a
bit of
On 5/15/2018 3:48 AM, saga...@nttdata.co.jp wrote:
We store the service logs which are created by VM on that storage.
I don't mean to be glib, but have you considered maybe not doing that?
--
Thanks,
Matt
___
OpenStack-operators mailing list
We have other scheduled tests that perform end-to-end (assign floating IP,
ssh, ping outside) and never had an issue.
I think we turned it off because the callback code was initially buggy and
nova would wait forever while things were in fact ok, but I'll change
"vif_plugging_is_fatal = True" and
On 5/17/2018 9:46 AM, George Mihaiescu wrote:
and large rally tests of 500 instances complete with no issues.
Sure, except you can't ssh into the guests.
The whole reason the vif plugging is fatal and timeout and callback code
was because the upstream CI was unstable without it. The server
We use "vif_plugging_is_fatal = False" and "vif_plugging_timeout = 0" as
well as "no-ping" in the dnsmasq-neutron.conf, and large rally tests of 500
instances complete with no issues.
These are some good blogposts about Neutron performance:
Hi,
unfortunately, didn't get the reply in my inbox, so I'm answering from the link
here:
http://lists.openstack.org/pipermail/openstack-operators/2018-May/015270.html
(hopefully, my reply will go to the same thread)
Anyway, I can see the neutron openvswitch agent logs processing the interface