Releases: LD4P/qa_server
v6.2.0
Actions Required to Upgrade
It is recommended that you update to this version if you are using any version from v5.2.0 upward. That release introduced the performance cache which has since been identified as the source of a memory leak. This release addresses that issue and provides more control over debugging loggers.
Update to qa_server v6.2.0 and run bundle install.
bundle update qa_server
Changes
Migrations
The scenario_run_history table has a new indexed column with the date of the run. This allows for more efficient calculations of the summary data for the history datatable and graph.
Run the migration install task to get the new migration:
rake qa_server:install:migrations
This should add migration:
- _add_date_column_to_scenario_run_history.qa_server.rb
Run migrations:
rake db:migrate
Debug logging
In v6.0.0, a logger was added for debugging the Monitor Status page, especially for tracking the caching of the generated statistics for that page. In this release, a second logger was added for debugging the performance cache. Also, all messages going to both these loggers are set using the debug level.
The default location for the monitor_logger is log/monitor.log. It can be changed by setting ENV['MONITOR_LOG_PATH'].
The default location for the performance_cache_logger is log/performance_cache.log. It can be changed by setting ENV['PERFORMANCE_CACHE_LOG_PATH']
These debugging loggers can be controlled by configuration options. See below for details.
New Configuration Options
There are several new configurations all of which are optional and have a default values.
logger related configs
Both loggers follow the default behavior of the Rails logger. That is, logger level for development is debug and logger level for production is info. The result of this is that both logs will by default be created in the development environment and will not for production. You can control this in all environments using the following configurations.
# Enable/Disable logging of performance cache
# Uncomment one of the lines below to enable or disable performance cache logging. NOTE: By default, loggers follow the
# default levels for Rails loggers (i.e. enabled for development, disabled for production.)
# config.enable_performance_cache_logging
# config.disable_performance_cache_logging
# Enable/Disable logging of monitoring process
# Uncomment one of the lines below to enable or disable monitoring process logging. NOTE: By default, loggers follow the
# default levels for Rails loggers (i.e. enabled for development, disabled for production.)
# config.enable_monitor_status_logging
# config.disable_monitor_status_logging
max performance cache size
Previously by default, the cache was written to the database once a day when the monitoring tests were run. There was a problem with the performance cache growing too large in previous releases during heavy usage. To address this, a configuration was added to set a max size for the cache. If it is exceeded, the cache will be written to the database immediately and the cache reset. To control the max size, set the following configuration.
# Maximum amount of memory the performance cache can occupy before it is written to the database.
# @param [Integer] maximum size of performance cache before flushing
# config.max_performance_cache_size = 32.megabytes
updating configurations for existing apps
It is recommended that you copy the new configurations to keep your local config file in sync with the configurations.
Copy only the new configs...
FROM: lib/generators/qa_server/templates/config/initializers/qa_server.rb
TO: config/initializers/qa_server.rb
authentication required for refreshing monitor tests
Questioning Authority (QA) has an authentication token for reloading authorities through the browser. QaServer makes use of that same token to control refreshing of data on the Monitor Status page. This addresses the potential risk of a denial of service attack where repeatedly requesting a refresh could exceed application resources.
You can set the authentication token in the QA initializer. (i.e., config/initializers/qa.rb)
Change Log
- use authentication for refreshing monitor tests
- add performance cache logger
- exceeding max performance cache size flushing the cache
v6.1.0
Actions Required to Upgrade
Update to qa_server v6.1.0 and run bundle install.
bundle update qa_server
Updates
This makes minor updates to monitor status functionality to make the statistics calculate according to stated expectations. Specifically, the history datatable was calculting pass/fail for all tests. It was supposed to be showing number of passing/failing days. With this release, that is now what the stats show.
This release also includes updates to the authority configs to config v2.2. This version of configs adds in support for pagination. And includes new authority config for CERL.
Change Log
- change historical summary to show number of days instead of number of tests (original intent)
- default tests to connection tests
- update authorities to v2.2 configs
- add authority cerl_ld4l_cache
v6.0.0
Actions Required to Upgrade
Update to qa_server v6.0.0
bundle update qa_server
Changes
The major change in this release is improved caching of data for the monitor status page and the running of monitoring tests in background. This prevents the page from reporting errors due to timeouts.
There are a few other refactors which impact public method APIs, thus causing the major release. Functionally, everything remains the same. The changes impact the Admin UI only and have no impact on the search and fetch APIs.
New Configuration Options
There is one new configuration which is optional and has a default value.
The datatable under Authority Connection History on the Monitor Status page previously calculated from all available data. A new configuration was added to allow sites to control the time period that is used to calculate data for the history graph and datatable.
config.historical_datatable_default_time_period = :year
It is recommended that you copy the new configurations to keep your local config file in sync with the configurations.
Copy only the new configs...
FROM: lib/generators/qa_server/templates/config/initializers/qa_server.rb
TO: config/initializers/qa_server.rb
Change Log
- refactor generation of performance graphs to minimize db access and calculations
- shorten race_condition times for caching
- rename jobs_logger to be monitor_logger
- run monitoring tests in background
- move methods from QaServer to services
- use presenter to get failure data
- move controller validation code to module include
- limit historical data to configurable time period
- move time_period where clause construction to service
v5.5.1
v5.5.0
Use caching with expiry for monitor status page.
Cached…
- summary table data for latest run
- failures for latest run, if any
- authority connection history
- performance graph data
- performance data table data
Allows forced refresh in the same way as done previously.
v5.3.0
Change Log
- optionally log browser and platform user agent info
- update to qa 5.3
- add a request id to the search and find request headers
- log exception for graph load failures
- optionally include IP info at start of search/find linked data requests
Actions
Logging of IP and browser/platform data are suppressed by default. To include this information in the log, edit config/initializers/qa.rb and set the following...
config.suppress_ip_data_from_log = false
This is part of the QA 5.3 release. Note that if you want the additional logging, you should make sure that QA is at release 5.3.1. The logging added at 5.3.0 was not robust and throws an exception if the location or user agent data could not be extracted from the result. Release 5.3.1 handles this situation gracefully and without failure.
v5.2.1
Bug fix only - add defaults for expiry configs to configuration initializer generator
Two other commits were made, but were then reverted, as that functionality was moved to QA release 5.3.0.
- log failure when graph load fails
- add GraphService prepend to generated application.rb
v5.2.0
Action Required
This is a minor release that is fully backward compatible.
New Features
Control when monitoring page regenerates
It is a very slow process to run all the monitoring tests. The monitor page is setup to run the monitoring tests only once a day. The rest of the time, it reports back the results from the last test run.
Previously the expiration of these tests was a set time. The first access after the expiration time causes the full set of monitoring tests to run. It can now be controlled by configurations.
QaServer.config.preferred_time_zone_name = 'Eastern Time (US & Canada)' (default)
QaServer.config.hour_offset_to_run_monitoring_tests = 3 (default)
The offset is calculated from midnight. With the default values, the monitoring tests will expire at 3am ET. This places the slowdown at midnight PT/3am ET. To use on the west coast, the values would be 'Pacific Time (US & Canada)' and 0 for midnight to have the slowdown at midnight PT/3am ET.
NOTE: You can use a cron job or monitoring to visit the monitoring page just after the expiration time and again a while later to check the status once the tests have completed. This will prevent the slowdown from occurring during normal business hours.
Cache performance data
Instead of updating the performance history in the database with each request, it will now only write once a day. This addresses an issue where writing with every request was causing connection pool timeouts.
Change Log
- set monitoring to expire nightly at 3am ET by default
- save performance data once a day when running monitoring tests
- setup travis-ci to run
v5.1.0
Action Required
This is a minor release that is fully backward compatible.
New Configuration
QaServer.config.suppress_performance_gathering = true|false (default is false for backward compatibility)
Currently there is a write to the database with every request to record performance data. If that becomes in itself a performance challenge, it can be turned off by setting QaServer.config.suppress_performance_gathering=true in code or in the qa_server initializer.
Change Log
- allow suppression of performance data gathering