[dev.icinga.com #10971] Services created on satellite without name fail when synchronizing with master.

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/10971

Created by pkcinna on 2016-01-14 13:59:58 +00:00

Assignee: pkcinna
Status: Rejected (closed on 2016-01-21 08:12:40 +00:00)
Target Version: (none)
Last Update: 2016-01-21 08:12:40 +00:00 (in Redmine)

Icinga Version: v2.4.1
Backport?: Not yet backported
Include in Changelog: 1

---

Example below with name commented out works fine from satellite but if another icinga tries to sync it will cause a an invalid service name on master.

Config on satellite:
apply Service for ( svc in host.vars.training_service_paths) { import "check-svc-service" vars.tmo_platform = host.vars.tmo_platform vars.tmo_env = svc[0] groups += [ svc[0] + " " + svc[1] ] notes_url = "/check_service/notes.php?service_category=" + host.vars.tmo_platform + "&env=" + svc[0] + "&service=" + svc[1] + "&method=" + svc[2] //name = svc[0] + " - " + svc[1] + " " + svc[2] display_name = svc[0] + " - " + svc[1] + " " + svc[2] vars.tmo_service_paths = svc[1] + "/" + svc[2] assign where host.vars.tmo_platform == "training" }

Sync on master generates services names with lots of quotes:
sudo icinga2 node update-config sudo service icinga2 checkconfig

information/ConfigCompiler: Compiling config file: /etc/icinga2/repository.d/zones/devemon101.unix.gsm1900.org.conf
critical/config: Error: syntax error, unexpected T_IDENTIFIER, expecting '{'
Location: in /etc/icinga2/repository.d/hosts/tstsvrt003.unix.gsm1900.org/[ %22training%22, %22mpos%22, %22ebs%2FCommerceManagement%2FAuthentication%2FcreateSession%22 ].conf: 1:19-1:26
/etc/icinga2/repository.d/hosts/tstsvrt003.unix.gsm1900.org/[ %22training%22, %22mpos%22, %22ebs%2FCommerceManagement%2FAuthentication%2FcreateSession%22 ].conf(1): object Service "[ "training", "mpos", "ebs/CommerceManagement/Authentication/createSession" ]" {

Attachments

• training.conf pkcinna - 2016-01-14 21:18:39 +00:00 - config with apply loop
• tstsvrt003.conf pkcinna - 2016-01-14 21:18:39 +00:00 - config with array used in apply
• tstsvrt003.unix.gsm1900.org.tar pkcinna - 2016-01-14 21:18:40 +00:00 - generated services from apply

---

Relations:

• duplicates #10971

[icinga-migration]

Updated by mfriedrich on 2016-01-14 14:36:17 +00:00

• Status changed from New to Feedback
• Assigned to set to pkcinna

That config does not match the error message. Please attach the config file from the output.

[icinga-migration]

Updated by pkcinna on 2016-01-14 21:24:29 +00:00

• File added training.conf
• File added tstsvrt003.conf
• File added tstsvrt003.unix.gsm1900.org.tar

It looks like if no name is set the name is created from the loop value but that is an array itself so when converted to a string, it has embedded quotes

Example:
object Service "[ "training", "mpos", "jpay/performDuplicatePaymentCheck" ]" {
import "satellite-service"
check_command = "dummy"
host_name = "tstsvrt003.unix.gsm1900.org"
zone = "devemon101.unix.gsm1900.org"
}

[icinga-migration]

Updated by mfriedrich on 2016-01-15 07:46:46 +00:00

That's how apply for is designed to work - taking the value from an array, or the key from a dictionary in a for loop. Yours is a nested array, wouldn't that better fit as dictionary with the service name as key, and the list of whatever as array?

Imho this is a config issue, not a bug.

[icinga-migration]

Updated by pkcinna on 2016-01-15 12:40:06 +00:00

I agree it may seem minor but in my opinion it needs to be consistent... either invalid on both the satellite and the master or valid on both.

For example...
Team A has their own Icinga instance for development and configures it however they want.
There is a master Icinga owned by the monitoring team which periodically gets updates from all the satellites owned by other teams.
In this scenario it seems the main Icinga will not be able to import the config of Team A without asking them to fix their config.

[icinga-migration]

Updated by gbeutner on 2016-01-21 08:12:40 +00:00

• Status changed from Feedback to Rejected

The real problem here is that the object's name isn't quoted properly, i.e. this is a duplicate of #10989.

[icinga-migration]

Updated by gbeutner on 2016-01-21 08:12:51 +00:00

• Duplicated set to 10989