[Openstack-operators] State of Juno in Production
jon at jonproulx.com
Tue Feb 17 20:17:57 UTC 2015
Recently (4 weeks?) moved from Icehouse to Juno. It was pretty smooth
(neutron has been much more well behaved though I know that's not
relevant to you).
One negative difference I noticed, but haven't really dug into yet
since it's not a common pattern here:
If I schedule >20 instances in one API call I get conductor timeouts
and zero launches. If I make many parallel scheduling calls for <20
instances each response is good and scaling out to several hundred
parallel launches is much faster and with out the neutron timeout
errors that plagued me since I switched over to quantum in Grizzly.
As I said I've not looked deeply at this so it may be a local config
issue rather than something systemic with Juno, but if it's an
important use case for you be sure to take a good look at it.
On Tue, Feb 17, 2015 at 12:56 PM, Joe Topjian <joe at topjian.net> wrote:
> Nice - thanks, Jesse. :)
> On Tue, Feb 17, 2015 at 10:35 AM, Jesse Keating <jlk at bluebox.net> wrote:
>> On 2/17/15 8:46 AM, Joe Topjian wrote:
>>> The only issue I'm aware of is that live snapshotting is disabled. Has
>>> anyone re-enabled this and seen issues? What was the procedure to
>> We've re-enabled it. Live snapshots take more system resources, which
>> meant I had to dial back down my Rally test to validate how it could
>> To re-enable it, we reverted the upstream commit that disabled it.
>> Once that was clear, and we had an upgraded version of libvirt in place,
>> live snapshots just happened.
>> As for the rest of your mail, we're going from Havana to Juno, and we have
>> neutron, so some of our experience won't necessarily apply to you.
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators