Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More recent changes in the configuration are overwritten by the modified-attributes.conf #8717

Closed
mcodato opened this issue Apr 14, 2021 · 2 comments
Assignees
Labels
area/api REST API area/configuration DSL, parser, compiler, error handling bug Something isn't working

Comments

@mcodato
Copy link
Contributor

mcodato commented Apr 14, 2021

Describe the bug

The modified-attributes.conf, written after an API call, has precedence over the other config files even if they were
changed and deployed more recently from the icingaweb2 module director.

To Reproduce

1 host with address 192.168.1.1 in package director.

  1. Via the API, set the host address to 192.168.1.20.
  2. Change the host address via the icingaweb2 module director to 192.168.1.30.
  3. Execute the deployment.
  4. In the monitoring the host address remains 192.168.1.20.

Expected behavior

The IP address after the deployment should be 192.168.1.30

Your Environment

  • Version used (icinga2 --version):
icinga2 - The Icinga 2 network monitoring daemon (version: 2.12.3)
Copyright (c) 2012-2021 Icinga GmbH (https://icinga.com/)
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
System information:
Platform: CentOS Linux
Platform version: 8
Kernel: Linux
Kernel version: 4.18.0-240.22.1.el8_3.x86_64
Architecture: x86_64
Build information:
Compiler: GNU 8.3.1
Build host: runner-hh8q3bz2-project-322-concurrent-0
OpenSSL version: OpenSSL 1.1.1g FIPS  21 Apr 2020
Application information:
General paths:
Config directory: /etc/icinga2
Data directory: /var/lib/icinga2
Log directory: /var/log/icinga2
Cache directory: /var/cache/icinga2
Spool directory: /var/spool/icinga2
Run directory: /run/icinga2
Old paths (deprecated):
Installation root: /usr
Sysconf directory: /etc
Run directory (base): /run
Local state directory: /var
Internal paths:
Package data directory: /usr/share/icinga2
State path: /var/lib/icinga2/icinga2.state
Modified attributes path: /var/lib/icinga2/modified-attributes.conf
Objects path: /var/cache/icinga2/icinga2.debug
Vars path: /var/cache/icinga2/icinga2.vars
PID path: /run/icinga2/icinga2.pid
  • Icinga Web 2 version: 2.8.2
  • Icinga Web 2 Module Director version: 1.8.0

Additional context

This relates to the hot deployment feature discussed in the following issue:
#8639

@Al2Klimov
Copy link
Member

Sounds like #8036.

@Al2Klimov Al2Klimov self-assigned this Apr 21, 2021
@Al2Klimov Al2Klimov added area/api REST API area/configuration DSL, parser, compiler, error handling bug Something isn't working labels Apr 21, 2021
Al2Klimov added a commit that referenced this issue Apr 22, 2021
Al2Klimov added a commit that referenced this issue Apr 22, 2021
Al2Klimov added a commit that referenced this issue Apr 22, 2021
Al2Klimov added a commit that referenced this issue Apr 22, 2021
Al2Klimov added a commit that referenced this issue Aug 11, 2021
Al2Klimov added a commit that referenced this issue Aug 11, 2021
Al2Klimov added a commit that referenced this issue Aug 11, 2021
Al2Klimov added a commit that referenced this issue Aug 11, 2021
@julianbrost
Copy link
Contributor

While "more recent changes in the configuration [file]" sounds trivial/obvious from a user perspective, for Icinga 2, these config files are just there containing objects/values without any context or history information. Therefore, it would be really hard to deduce the user's intention from a config file and an attempt to implement this under these circumstances would probably introduce undesired behavior in other situations.

When updating file-created objects via the API, this should probably be treated as a way to manage overrides on that object that shadow values from the config files (including those deployed from Director) and clear them using something like #8036.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api REST API area/configuration DSL, parser, compiler, error handling bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants