claranet/terraform-signalfx-detectors v1.0.0

on GitHub

1.0.0 (December 7, 2020)

UPGRADE NOTES:

• The terraform modules source path in your stack configuration requires to be updated to use to new module path in /modules root directory to meet terraform registry requirements.
  Please follow this doc to update any existing configuration.
• You can use, if you prefer, the terraform registry from now as source instead of the git or github source types.

BREAKING CHANGES:

• All existing stack configuration using path from the old tree structure will fail for every modules using v1+ tag with the error "no module found"
  The tag v0.4.1 contains exactly same features than v1.0.0 on the detectors scope and it will be the last one supporting tree structure.

NOTES:

• It has the same functional scope than https://github.com/claranet/terraform-signalfx-detectors/releases/tag/v0.4.1 and if resource is preserved in the state file after upgrade you should not see any diff. Its changes mainly focus move from tree to flat structure, enrich documentation, improve CI and provide tooling to help developer to contribute
• It is the first version compatible with the terraform registry using a flat structure. All modules are now available here as a flat directories list.

NEW FEATURES:

• provide full modules list and one stack example in terraform registry which become the documentation start point to use a module.
• rework and refactor scripts splitting them into 2 directories module to work on modules changes as dev or stack to generate terraform source to use by end user.
• modules readmes are all generated from a template with a jinja based generator
• detector generator: add support for extrapolation, vm filters, heartbeat subject
• convert most of the detectors from system-common module into yaml configuration as example of using yaml config files and the generator to create new detectors
• add a new makefile which help to setup the tooling environment and perform automation tasks like generate detectors from config files, auto update readme, bootstrap a new module or a new stack..

DOCUMENTATION:

Documentation exist in 2 locations: inside this repository and inside its wiki. Each one has a different purpose.

• In the repo and especially docs root directory, the documentation provides an operational quick start. The users can learn how to deploy detectors easily to test before to go deeper.
  The developers will find tasks to do for every common types of changes known like creating a new detector or a new module.

• Wiki has been improved to provides a conceptual understanding with everything useful to go further in the usage or the development of this project. Users will find advanced usages tricks or tips and more detailed procedures. Developers could learn how it works under the hood to propose global enhancements which could impact all modules.