Abel Lopez writes:
I saw this last commit to jdurgin's nova fork which solves the issue (
https://github.com/jdurgin/nova/commit/ea4b5369e4bec4dd7a0ce9f68769600329cda6c6
)
now a snapshot happens in seconds.
The problem that we've introduced however, is that about 15-20m after
we do a
Michael Stang writes:
> Is this one the actual guid for upgrades, and is it valid for every
> upgrade or ony for specific versions?:
> http://docs.openstack.org/ops-guide/ops_upgrades.html
Yes, that's part of the official Operations Guide. It is not
version-specific. The examples are based on
Nick Jones writes:
> Another vote of confidence for the script that Tim has mentioned with
> regards to clearing down Nova’s DB. I blogged a bit about the process
> and the results here:
> http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/
Unfortunately the
Shamail Tahir writes:
> The AUC Recognition WG has been hard at work on milestone-4 of our
> plan which is to identify the eligibility criteria for each community
> contributor role that is covered by AUC.
> [...] Thank you in advance for your feedback!
+1
Looks good, thanks all for the work
Here's the initial Etherpad for the Wednesday afternoon session
"DO NOT DO... UNDER ANY CIRCUMSTANCES":
https://etherpad.openstack.org/p/MIL-ops-scaling-and-tuning
Please add your war stories and "lessons learned".
Thanks & looking forward to the discussion in Milan!
--
Simon.
Here's the initial Etherpad for the Wednesday afternoon session on
SCALING & TUNING:
https://etherpad.openstack.org/p/MIL-ops-scaling-and-tuning
Please contribute your tuning tips (and questions),
scaling woes (and solutions), etc.
Thanks & looking forward to the discussion in Milan!
--
Simon.
Here's the initial Etherpad for the Wednesday afternoon session
"DO NOT DO... UNDER ANY CIRCUMSTANCES":
https://etherpad.openstack.org/p/MIL-ops-do-not-do
[Corrected link - thanks Maxime Guyot for pointing out the error!]
Please add your war stories and "lessons learned".
Thanks & looking
Lars Kellogg-Stedman writes:
> I'm curious what folks out there are using for chargeback/billing in
> your OpenStack environment.
We use a homegrown billing system that periodically samples utilization
of billable resources.
(We turned off Ceilometer a few years ago because we weren't really
Artom Lifshitz writes:
> To that end, we'd like to know what filters operators are enabling in
> their deployment. If you can, please reply to this email with your
> [filter_scheduler]/enabled_filters (or
> [DEFAULT]/scheduler_default_filters if you're using an older version)
> option from
Jean-Philippe Méthot writes:
> This particular message makes it sound as if openvswitch is getting
> overloaded.
> Sep 23 03:54:08 network1 ovsdb-server:
> ovs|01253|reconnect|ERR|tcp:127.0.0.1:50814: no response to inactivity probe
> after 5.01 seconds, disconnecting
We get these as well :-(
10 matches
Mail list logo
