Releases: Dynatrace/dynatrace-configuration-as-code
2.3.0
What's Changed
🚀 Features
- Monaco now extracts all found Monitored Entities Identifiers and UUIDs into Monaco variables.
🐛 Fixes
- Compound variables are now converted correctly from Monaco 1 to Monaco 2.
🔧 Improvements
- Improved the hint when the URL to a Dynatrace environment was misconfigured.
- Improved logging for pagination
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.3.0
Verifying Signature
The Image is signed, and its signature can be verified using cosign and the cosign.pub
key that can be downloaded from this release.
cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.3.0
Full Changelog: v2.2.0...v2.3.0
2.2.0
What's Changed
🚀 Features
- Monaco can switch between 'normal' and 'structured' logging.
- Can be turned on via environment variable
MONACO_LOG_FORMAT=json
- This will be extended in future versions.
- Can be turned on via environment variable
- Monaco can be configured to log in UTC instead of local time.
- Can be turned on via environment variable
MONACO_LOG_TIME=utc
- Can be turned on via environment variable
- Skip download of unmodifiable settings objects.
- The Settings API newly provides information about objects being modifiable or not. This is used to ensure all downloaded Settings can be deployed/updated.
- Allow deactivation of download filters if needed.
🐛 Fixes
- Uniformly create UUID of 'non-unique-name' config API type on Windows and Linux/Mac
- Can be turned off with
MONACO_FEAT_CONSISTENT_UUID_GENERATION=false
if needed to ensure backwards compatibility for configs deployed from Windows.
- Can be turned off with
- Preset dashboards are downloaded if they're not owned by Dynatrace.
- Correctly convert "environment overrides" for v1 configurations with overlapping IDs.
- Conversion ensures that no config of the same type can have the same ID (v1 didn't validate against that). Previous versions lost environment overrides for such renamed config IDs.
🔧 Improvements
- Deployment is retried on additional known synthetic config API errors
- An error is reported if a user defines a project without a name by accident.
- An error is reported if a "Classic Config API" configuration references a Settings config ID. As Settings work with new base64 Object IDs, the older Config APIs don't understand Settings IDs.
- Docker container base image is updated to latest alpine 3.18.
- Docker container is now signed with cosign.
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly, or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.2.0
Verifying Signature
The Image is signed, and its signature can be verified using cosign and the cosign.pub
key that can be downloaded from this release.
cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.2.0
Full Changelog: v2.1.1...v2.2.0
2.1.1
What's Changed
Fixes
- Allow backslashes in relative template paths
When a project is created by a Windows user, the paths might contain backslashes () instead of slashes (/) for path separation.
This is not an issue if the project is deployed in Windows again, but if it's deployed on a Linux environment, for example in Linux-CI systems, the path could not be resolved.
This bugfix allows backslashes in template paths, as a Windows user might also manually create the path, and Monaco should handle it correctly. - Allow environment override of
OriginObjectId
OriginObjectId, which is used to identify and "onboard" existing Settings objects to be managed via Monaco config-as-code, was not considered when applying environment overrides.
This made users who use a single Monaco configuration with overrides to manage an existing Setting on several environments unable to correctly "onboard" and deploy these Settings.
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly, or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.1.1
Full Changelog: v2.1.0...v2.1.1
2.1.0
What's Changed
Fixes
-
User-defined preset dashboards are ignored during download
In the earlier version of Monaco, dashboards labeled as "preset" were excluded from the download process to avoid potential errors when (re)deploying them, as these dashboards couldn't be modified by the user. However, it was discovered that user-defined dashboards could also be marked as "preset." This fix introduces a change in behavior, ensuring that preset dashboards created by the user are no longer skipped during the download process. -
Missing custom user-agent header in
HTTP
calls
In one of the previous releases, the setting of a dedicated user-agent when making HTTP calls to the Dynatrace API was lost. This fix restores the functionality of setting the user-agent, which is essential for usage tracking and enables visibility into the Monaco API calls reaching the cluster for support purposes. -
Environment overrides are lost during
v1/v2
conversion
The previous conversion failed to consider v1 environment overrides, which are of the form[config ID].[environment]
. This fix overwrites config IDs both for the base property and any that follow the format of a v1 override.
Features / improvements
-
Write downloaded configs in a stable order
Until now, it was pretty hard to compare the configs as they were written in the order we downloaded them.
This change orders the configs before writing them to files, thus simplifying comparing incremental changes or the difference between two environments. We achieve the ordering by simply ordering by the config-id within a file, as the API already splits downloaded files, and thus, the ID is unique within a file. -
Use full coordinate when generating external IDs for Settings 2.0 Objects
We've changed the way we generate external IDs for settings 2.0 objects to use the "full Coordinate" (project name, schema id and monaco id) in order to support distinguishing the same configuration stored in different projects.
To stay backward compatible, we still calculate the "old" external id (without the project name included) and try to update already existing settings objects accordingly. -
Introduce structured delete definition
As the 'externalID' by which Settings are identified by monaco is extended to include the project (full coordinate - project,type,id) - the simple string format is no longer enough to define delete entry.
A new format is added that defines a structured project, type, and name or ID delete entry.
Delete YAML format changes to a structured format:
delete:
- project: "project"
type: alerting-profile
name: "Star Trek Service"
- project: "project"
type: builtin:settings20.schema
id: super-awesome-config
Loading is extended to be able to load both the full and the old simple format. The old format is still usable, but for settings 2.0 objects it will produce a warning log.
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly, or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.1.0
Full Changelog: v2.0.3...v2.1.0
2.0.3
What's Changed
Fixes
- fix: Download filters were not applied when downloading ALL config API types
- This re-introduces base API filtering (deprecated APIs and 'SkipDownload' APIs) when downloading without defining specific classic APIs to download. (broken in 2.0.2)
- Downloading all types will again skip deprecated classic config types.
This is especially relevant for those that are deprecated by Settings, as we currently would download both and result in an undefined state on deployment as the content of configs and Settings might subtly differ and upload order is not stable.
Improvements
- feat(deploy): Log number of projects, environments and (on debug) configs to deploy
- refactor(download): Replace aho-corasick implemenation used in fast dependency resolver by a more memory efficient one
- The fast dependency resolver is still memory intensive but less so.
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly, or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.0.3
Full Changelog: v2.0.2...v2.0.3
2.0.2
Improvements
Dependency Resolution on Download
When downloading configurations, the CLI finds dependencies between configurations and creates the required references in the config YAMLs.
This operation is resource intensive and, for large environments, requires either time/CPU or memory.
Previous 2.x releases used a fast, but memory intensive implementation by default - which can cause issues for resource constraint setups, like VMs or containers with low memory and a hard memory limit/no swap space.
2.0.2 includes to changes:
- Use the 'slower' CPU intensive resolver by default - while dependent on available CPU, this resolver is much less likely to hit hard memory limits and just gets slower if CPU/threads are limited.
- Allow switching between fast and basic dependency resolvers when downloading
- The fast resolver is still available by setting the environment variable
MONACO_FEAT_FAST_DEPENDENCY_RESOLVER=true
- To use this 'fast resolver,' please ensure the machine has at least 16-32GB of RAM and several hundred GB of storage available as swap space.
- The fast resolver is still available by setting the environment variable
Full Changelog: v2.0.1...v2.0.2
2.0.1
Monaco 2.0.1
Improvements
- #945 Download: Improve Autocompletion
Bugfixes
- #946 #961 Management-Zone Setting IDs are now correctly resolved
- #951 request-attributes configs are no longer marked as deprecated
- #959
netgo
tag is no longer included for Windows builds. This makes switching to the cgo DNS resolver possible again. - #962 During download, projects are no longer overwritten if
--force
is not given - #963 Fixed a timing issue for resource creation
Dependency updates
- #940 bump github.com/spf13/cobra from 1.6.1 to 1.7.0
- #953 bump golang.org/x/oauth2 from 0.6.0 to 0.7.0
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly, or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.0.1
Full Changelog: v2.0.0...v2.0.1
2.0.0
Monaco 2.0.0
Version 2.x tries to achieve three main goals:
- Make the CLI and configuration clearer to understand
- With more explicit commands
- Structured configuration YAML
- Decouple from the file-path
- Monaco 1.x was impacted by the location it was executed in, in relation to the configuration
- Provide general support for Settings 2.0 configuration
- Monaco 2.0 does not need to be updated to support future settings schemas
- In part possible due to the new structure
To achieve these goals, configuration structure changes substantially over version 1.x.
Getting Started
The documentation for 2.0.0 is available here
Also, check out the Observability Clinic introducing Monaco 2.0.
And the related sample configurations
Migrating from 1.x
We aim to make migration a no-effort change.
To learn how you can use the monaco convert
command to migrate to 2.x, follow this guide.
Major Changes
- Structured configuration
- Improved CLI commands
- General support for Settings 2.0 configurations
- Numerous improvements and bugfixes
- Ready to access Dynatrace Platform environments using OAuth2 authentication
Breaking changes over preview release versions
If you have already been using the preview release versions, first off: thank you for your feedback!
Second, there are a few changes to be aware of:
Breaking changes over latest rc.8 preview
Usage for the monaco dowload
and monaco delete
commands changes compared to the latest rc.8 preview.
Download changes
Rather than having download manifest
and download direct
sub-commands, configuration is moved to flags.
Download can be called as:
# download from specific environment defined in manifest.yaml
monaco download [--manifest manifest.yaml] --environment MY_ENV ...
# download without manifest
monaco download --url url --token DT_TOKEN [--oauth-client-id CLIENT_ID --oauth-client-secret CLIENT_SECRET] ...
Note that this also introduces --oauth
authentication flags for downloading from Platform environments.
Delete changes
Delete gains a matching manifest flag and default values for both the manifest and delete file name
monaco delete --manifest <manifest.yaml> --file <delete.yaml> [flags]
Breaking changes introduced in the latest rc.8 preview release
If you had not yet upgraded to the latest preview version, be aware of the following breaking changes compared to earlier versions:
The manifest.yaml
-configurations are not fully compatible with the rc.6 preview:
- Specifying
[config].token
will now throw an error. It has to be moved to[config].auth.token
. For example:manifestVersion: 1.0 projects: - name: project environmentGroups: - name: environment-group environments: - name: environment-name url: value: "https://example.com" auth: token: name: TOKEN_ENV_VAR
- Removal of
[config].type
. If you downloaded Dynatrace configuration usingmonaco download …
, it might be that you have to remove this field.
Container image
Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code
The image can be used directly, passing command arguments to the CLI directly, or in CI with a monaco
executable available in the container.
docker pull dynatrace/dynatrace-configuration-as-code:2.0.0
Full Changelog: v1.8.9...v2.0.0
Preview Release 2.0.0-rc.8
⚠️ Preview Release
This is a pre-release of monaco 2.0.0.
- this does not yet reflect the full content or quality of the final release
- no official support is provided for the pre-release version
- please let us know your feedback #813
Monaco 2.0.0 Changes
Version 2.x tries to achieve three main goals:
- Make the CLI and configuration clearer to understand
- With more explicit commands
- Structured configuration YAML
- Decouple from the file-path
- Monaco 1.x was impacted by the location it was executed in, in relation to the configuration
- Provide general support for Settings 2.0 configuration
- Monaco 2.0 does not need to be updated to support future settings schemas
- In part possible due to the new structure
Getting Started
A preview of the documentation for 2.0.0 is available here
Also, check out the Observability Clinic introducing Monaco 2.0.
And the related sample configurations
⚠️ Breaking changes since rc.6:
The manifest.yaml
-configurations are not fully compatible with the rc.6 preview:
- Specifying
[config].token
will now throw an error. It has to be moved to[config].auth.token
. For example:manifestVersion: 1.0 projects: - name: project environmentGroups: - name: environment-group environments: - name: environment-name url: value: "https://example.com" auth: token: name: TOKEN_ENV_VAR
- Removal of
[config].type
. If you downloaded Dynatrace configuration usingmonaco download …
, it might be that you have to remove this field.
What's Changed
- Allow users to specify oauth credentials in the manifest by @Laubi in #876
- chore: refactored deploy function by @warber in #881
- fix: fix failing v1 test by @warber in #884
- fix: fix Dockerfile by @jskelin in #882
- build: Ensure build-release make target works without arguments by @UnseenWizzard in #885
- Fix SBOM content and change action to upload to release directly by @UnseenWizzard in #886
- fix(docker): Ensure additional arguments can actually be passed to Docker container by @UnseenWizzard in #887
- Refactor/remove interface from api by @jskelin in #860
- fix(config): Add 'name' to list of reserved parameters by @UnseenWizzard in #888
- feat: check cluster generation download/deploy by @warber in #883
- chore: general cleanup by @warber in #893
- feat: Load only required environments by @Laubi in #889
- chore(deps): bump actions/setup-go from 3 to 4 by @dependabot in #896
- fix: Field names are wrong in warning message by @Laubi in #897
- chore: Add GitHub PR-template by @warber in #894
- Feat: Enable explicit specification of SSO OAuth token_endpoint in manifest.yaml by @jskelin in #892
- ci: Rename docker container image to dynatrace-configuration-as-code by @UnseenWizzard in #899
- Fix: Enhance cluster generation checks by @warber in #895
- chore: Add 'unit' build tag to newly added test by @UnseenWizzard in #901
- Change naming in
pkg/manifest
according to best practices / conventions by @jskelin in #900 ⚠️ Remove [config].token and [config].type (breaking change) by @Laubi in #898- fix: Log underlying error when Dynatrace generation check fails by @UnseenWizzard in #902
Full Changelog: v2.0.0-rc.6...v2.0.0-rc.8
Preview Release 2.0.0-rc.6
ℹ️ A newer Preview Relase of Monaco 2.0.0 is available ℹ️
⚠️ Preview Release
This is a pre-release of monaco 2.0.0.
- this does not yet reflect the full content or quality of the final release
- no official support is provided for the pre-release version
- please let us know your feedback #813
Monaco 2.0.0 Changes
Version 2.x tries to achieve three main goals:
- Make the CLI and configuration clearer to understand
- With more explicit commands
- Structured configuration YAML
- Decouple from the file-path
- Monaco 1.x was impacted by the location it was executed in, in relation to the configuration
- Provide general support for Settings 2.0 configuration
- Monaco 2.0 does not need to be updated to support future settings schemas
- In part possible due to the new structure
Getting Started
A preview of the documentation for 2.0.0 is available here
Also, check out the Observability Clinic introducing Monaco 2.0.
And the related sample configurations
What's Changed
- docs: Add correct links to v2 preview release and discussion by @UnseenWizzard in #814
- refactor: Remove legacy deploy by @Laubi in #815
- Ci/explicit workflow permissions by @UnseenWizzard in #823
- feat: Implement Version Check for Settings 2.0 Upload on older DT servers by @warber in #818
- feat: Added
monaco version
command by @warber in #822 - Refactor: Remove dead code & move simple packages by @Laubi in #820
- refactor: simplify filtering in api by @jskelin in #821
- 🐛 Windows can't store files with a colon ( : ) by @Laubi in #826
- feat: Allow HTTP urls by @Laubi in #827
- ci(e2e): Only run release binary build on main or e2e label by @UnseenWizzard in #830
- ci(e2e): Actually match checkout conditions to run e2e build step by @UnseenWizzard in #831
- Ci/adapt nosemgrep location by @UnseenWizzard in #829
- chore: move code from public util package to internal by @warber in #832
- chore: cleanup packages by @warber in #833
- Fix/rewrite settings ids for e2e tests by @UnseenWizzard in #835
- Include license texts in generated SBOM by @UnseenWizzard in #838
- Fix: Enhance settings upsert logic to work with current enhancements of the settings API by @warber in #834
- Fix/make test suffix available as env var by @UnseenWizzard in #840
- chore(deps): bump github.com/spf13/afero from 1.9.3 to 1.9.4 by @dependabot in #839
- chore: Fix dependabot reviewer group by @UnseenWizzard in #841
- chore(deps): bump github.com/stretchr/testify from 1.8.1 to 1.8.2 by @dependabot in #842
- Fix/setup client correctly in e2e tests by @UnseenWizzard in #844
- test(e2e): Assert created configs instead of logs in pagination test by @UnseenWizzard in #843
- Improve dependency resolution & topology sort performance by @Laubi in #836
- Restructure cmd package and split runner.go by @Laubi in #845
- chore: Cleanup v1 environment interface by @warber in #847
- refactor: Remove dependency from client to manfiest and extract/reuse E2E test util code by @UnseenWizzard in #846
- refactor: Remove unused getToken method by @Laubi in #849
- feat: Allow defining the environment-type in the manifest by @Laubi in #850
- fix: References are not parsed correctly by @Laubi in #852
- Feat: Prepare
DynatraceClient
to support OAuth authorization by @warber in #851 - fix: Conversion - Create config name where none exists by @Laubi in #854
- chore(deps): bump golang.org/x/net from 0.6.0 to 0.7.0 by @dependabot in #853
- chore(deps): bump golang.org/x/oauth2 from 0.5.0 to 0.6.0 by @dependabot in #859
- refactor: remove unused argument by @jskelin in #855
- refactor: remove usage of deprecated function by @jskelin in #856
- Fix: Handle duplicate config IDs when converting v1 config by @warber in #858
- Refactor: Small cleanups of deploy logic by @warber in #862
- chore(deps): bump github.com/spf13/afero from 1.9.4 to 1.9.5 by @dependabot in #864
- ♻️ Simplify Manifest URL handling by @Laubi in #863
- feat: Define internal representation for OAuth by @Laubi in #865
- refactor: Removed getEnvFromManifest file by @warber in #866
- feat(delete): Remove restriction on delete yaml filename by @UnseenWizzard in #867
- feat(download): Reduce default concurrent downloads to 5 by @UnseenWizzard in #873
- Feat/sign binaries 3 by @jskelin in #872
- feat(docker): Update base image to latest 3.17 alpine by @UnseenWizzard in #875
- fix: remove warning about unset server version in dynatrace client by @warber in #877
- fix: Extend error handling for paginated downloads / multithreaded downloads / entity downloads by @dcryans in #871
- feat(download): Rename concurrent request limit env var by @UnseenWizzard in #878
- fix(config): Wrap type definition errors in DefinitionParserError by @UnseenWizzard in #880
New Contributors
Full Changelog: v2.0.0-rc.4...v2.0.0-rc.6