Gitiles
Code Review Sign In
gerrit.mcp.mirantis.com / mcp / cfg-checker / 3bc95f6ff248b80380f709db4e92b42fc1da18c8
commit3bc95f6ff248b80380f709db4e92b42fc1da18c8[log] [tgz]
authorAlex <osavatieiev@mirantis.com>Thu Mar 05 17:00:04 2020 -0600
committerAlex <osavatieiev@mirantis.com>Tue Mar 10 18:27:36 2020 -0500
treeab345bd216403f13fff388a8b141daa1b7cd0b0c
parent2e213b2573f84188872a4ed0bf1cf76b901d9ddf [diff]
Migrating to Python v3

 - support for Python v3.8.x
 - support for Python v3.5.x
 - new tag, 2019.2.8
 - updates class generation and iterators
 - unittests updated with coverage >75%
 - new coverage routines
 - unittests profiling
 - full fake data for unittests
 - unittest testrun is ~1.5 seconds long

Bugfixes
 - 34834, proper use of 'sudo' option
 - multiple proper iterator use
 - 37919, show warning when installed and candidate versions
   are newer comparing to release version

Change-Id: Idd6b889f7ce94ae0c832e2f0a0346e4fdc3264a3
Related-PROD: PROD-34834 PROD-34664 PROD-34919
74 files changed
tree: ab345bd216403f13fff388a8b141daa1b7cd0b0c
  1. cfg_checker/
  2. etc/
  3. scripts/
  4. scripts_ds/
  5. templates/
  6. tests/
  7. versions/
  8. .coveragerc
  9. .gitignore
  10. cover.sh
  11. lastprofile.dat
  12. LICENSE
  13. profile.sh
  14. pstats.sh
  15. README.md
  16. requirements-test.txt
  17. requirements.txt
  18. runtests.py
  19. setup.py
README.md

salt-cfg-checker

This checker module is used to verify and validate cloud after the deployment using number of routines to create reports

Background.

Many of our deployments comes with the monitoring solutions, but none of them keeps track of the package versions that is included in release. nd it is very important to have proper package versions. That is critical for cloud stability. here is more, it is critical to keep track of configuration values for networks (and others too..) in Runtime, in Configuration and at Reclass. Also, it is important to keep track of the changes in reclass and be able to have tool that gives clear report on what has been changed.

So, this tool here that can do some checks on the cloud that will be handy for:

  • Engineers that deployed the clouds and need to be sure that proper versions installed on every node
  • Services Team to check cloud at deploy time
  • ProdCare engineers that is supporting client environments
  • Support team

Main use cases for the MCP-checker is:

  • Generate a package versions report that will show which package versions must be payed attention on: Installed vs Candidates vs Release Notes. This will really help on understanding if some node has some strangely versioned package
  • Generate network check against running nodes to collect IPs, mach them into subnets and check MTUs in Runtime (ip a) vs reclass configuration
  • Compare two reclass models recursively (folder1 vs folder2) and generate differences report.

Installation

It is pretty simple:

  • deploy on cfg node, using root creds, on /root/
git clone http://gerrit.mcp.mirantis.com/mcp/cfg-checker
cd cfg-checker
virtualenv .cfgcheck
source .cfgcheck/bin/activate
pip install -r requirements.txt
  • you can check your local.env file for parameters (no need to update for running on cfg node)

Running

  • Packages report (HTML): mcp_check packages report --html __packages_html_filename.html__
  • Packages report (CSV): mcp_check packages report --csv __packages_csv_filename.csv__
  • Network check (CLI output): mcp-checker network check
  • [Work in progress] Network check (HTML report): mcp-checker network report --html __network_html_filename.html__
  • List folders that can be used for Reclass Compare: mcp-checker reclass list -p __models_path__
  • Compare two Reclass models (file and parameter wise): mcp-checker reclass diff --model1 __model1_path__ --model2 __model2_path__ --html __reclass_html_filename.html__

External cloud

You can also create your env file to connect to env

  • create your *.env file or supply environment vars to module other way
  • in the env file set host and user for SSH. For options, use your ~/.ssh/config
  • if node listing fails, execute salt-key on master and create an etc/nodes.list file with minions list

Version history

  • [Done] Update messages to same style
  • [Done] Release versions support with customizable updates
  • [Done] Upgrades, errors and downgrades detection
  • [Done] Proper Debian package version naming convention support
  • [Done] Refactor parameter handling to have same naming for same options in different sections
  • [Done] Remove unneeded data from report
  • [Done] Add progress bar when processing along with handy stats
  • [Done] Add possibility to check cloud remotely
  • [Done] Add possibility to have several ready to use cloud connection configurations
  • [Done] Use flexible plugin structure to execute modules

TODO:

  • Check root on startup, exit
  • Prepare script to create venv
  • Reformat reclass compare file
  • Finalize Network check HTML report
  • Do simple rule-based checks on network
  • Implement simple packet sniff mechanics to check node-node VCP trafic flow
  • Add node params to output
  • Format reclass compare file

Cheers!