Sync Rule Problem

[DaMatze87]

Hi, I have a problem with syncing VM's. I've created an import source for vsphere and following sync rule:

First sync is working fine and is importing all 17 VM's. There are five not running and therefore having no IP. If I then check for changes it says there are some and want's to recreate the 12 running hosts and fails because these hosts already exists.

It seems it's ignoring the Update Policy. I tried all three policies (Replace, Merge, Ignore) and this error happens every time.

If you need further information please let me know and I try to provide them.

[Thomas-Gelf]

Hi @DaMatze87,

I guess you should be able to find the solution for your problem in the Key column name form field description:

This must be a column containing unique values like hostnames. Unless otherwise specified this will then be used as the object_name for the syncronized Icinga object. Especially when getting started with director please make sure to strictly follow this rule. Duplicate values for this column on different rows will trigger a failure, your import run will not succeed. Please pay attention when synching services, as "purge" will only work correctly with a key_column corresponding to host!name. Check the "Combine" property modifier in case your data source cannot provide such a field.

It should show the same text in German, it's Schlüsselspaltenname:

Muss eine Spalte sein, die eindeutige Werte wie Hostnamen enthält. Wenn nicht anders angegeben, wird dieser Wert dann als object_name für die synchronisierten Icinga Objekte verwendet. Insbesondere Benutzer mit wenig Erfahrung mit dem Director sollten sich unbedingt an diese Regel halten. Doppelte Werte in dieser Spalte erzeugen einen Fehler und der gesamte Importlauf schlägt fehl. Bitte beim Synchronisieren von Services Acht geben, "bereinigen" wird nur mit einer der host!name Syntax entsprechenden Schlüsselspalte funktionieren. Nutze den Eigenschaftsmodifikator "Kombinieren", falls die gegebenen Datenquelle keine solche Spalte bereitstellen kann

tl;dr: use guest.hostName as key column in your related Import Source definition.

Cheers, Thomas

[DaMatze87]

Hi Thomas,

thanks for your quick answer. My import source has the default value for key column name (name). If I try guest.hostName, I get the following error:

My import source config is as follows:

Greetings, Marcel

[Thomas-Gelf]

I have no test setup available right now. Could you please show me a full width screenshot of your Import Source preview? Please hide sensitive information and/or send me an email.

[epol]

Hi

any news on this issue? I have the same problem (but i'm using the 'config.uuid' variable).

I've also tried to add add a modifier config.uuid->uuid, in this case the import rule works, but the sync rules tries to recreate all objects every time.

Any hint would be helpful.

[Thomas-Gelf]

Hi @epol, @DaMatze87!

Main problem here:

• you must make sure that your key column (Import Source) matches the key column in your Sync Rule. Usually this is the object_name, and doesn't even need to be defined. But as soon as you define a custom object_name mapping you should be careful. And if you want updates and purges to work smoothly, having object_name matching the key column on the import source is a hard requirement. This is mentioned in some places and with more details in the description for the "Combine" property modifier. But I guess we should find a more prominent place for this, or show a bigger warning when object_name gets customized.
• you have an Import Source not giving you such a valid key column on every row

Said this, when choosing the guest host name instead of the VM's name as your key, there will be erroneous rows - usually those for hosts with no guest utilities installed. For this and similar use cases, I recently pushed the "Black- or White-list rows based on property value" row modifier to the Director master branch. It allow you to say "Skip all rows without a guest.hostName" and similar.

Cheers, Thomas

[epol]

It works! Thank you for the pointer, the decisive point was to have the object_name value match the key column.

Thank you! Enrico

[Thomas-Gelf]

You're welcome!