[dev.icinga.com #13447] There's no link between a template and its data fields

[icinga-migration]

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

Created by spillerm on 2016-12-07 08:59:30 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-12-13 07:53:31 +00:00 (in Redmine)

---

Hi,

I like working with data fields very much, and I like it to assign data fields to host templates. But when adding a template to a host, the assigned data fields are added in icinga_host_var without any "link" to the template.
A real problem for me is, that deleting such a template from a host configuration will not delete the assigned data field entries made in database (icinga_host_var).

I have to delete manually on database level - argh ;)

Regards,
Marianne

[icinga-migration]

Updated by tgelf on 2016-12-07 09:24:47 +00:00

Well... not so easy. Let me try to dig into this:

• vars and fields are intentionally separated. Fields define rules for the web frontend, vars carry the values
• there might be different field definitions for the same variable. Like "location" being a dropdown for Windows servers and a free text field for routers
• Import/Sync, REST API and CLI allow you to define whatever you want as a custom variable
• currently the only binding between the two is their name
• we do not know which field (or operation) has been used to define a specific var

So, there is a link between a template and it's fields, but there is no link between a field and vars populated using that field. Similar examples: when you completely delete a field you're currently asked whether Director should also delete all(!) vars with the same name. Doesn't happen in case you rename a field, that's a bug to me.

Technically I could easily link all vars to the field being used. Would be nice and clean and honestly my preferred way to go. Tasks making this more complicated:

• what should I do with synced values? Enforcing fields (= data types) could be the way to go, but we can't unless we support structured data types in our fields
• in the meantime it would be easy to not link imported vars to any data type
• but what should happen with properties once defined manually and then overridden via sync? Remove the link? And what if I now remove a related template?

So, given all this I could perfectly imagine adding at least a feature that (when deleting a template) does as follows:

• find all direct or indirect descendants of that template
• resolve and remember fields/vars for all of them
• remove the template
• resolve all fields/vars again
• compute the difference between those fields/var names

Now comes the tricky part. It's easy when an object completely looses a variable. Wipe it's value. Just: should I ask first? Makes the whole operation a little bit more complicated. And what if a variable name still exists, but is now inherited from another template with a different data type? Warn you? Silently ignore that fact? As it is either what your really want or otherwise something that would bite you next time you want to store that object?

Sorry for that wall of text. Or no, not so sorry. I'd love to hear your opinion on all of the above, so you have to read it anyways ;-)

Cheers,
Thomas

[icinga-migration]

Updated by spillerm on 2016-12-13 07:53:31 +00:00

Sorry for that wall of text. Or no, not so sorry. I'd love to hear your opinion on all of the above, so you have to read it anyways ;-)
I'll answer as soon as possible, but I have to think about that a while. But I thank you for your "wall of text" :) See it much clearer now.

Regards,
Marianne

[netzwerkgoettin]

Hi Tom,

it seems I had to think about a bit more.

Deleting a template from a host but keeping the vars is not the expected behaviour - that's my opinion and the feedback I'm getting from my users. In fact, it forces me to do magic on database level, with all the risk involved. Undesirable in production.

When removing a template from a host, all vars linked to that template should be deleted from that host; afterwards, the remaining templates etc. should be resolved and vars/fields (perhaps re-)assigned. Ask first? No. A brief summary would be nice to make clear what's going on, but I suspect that's a matter of taste.

Of course, my view on this is restricted to my infrastructure. My conclusion, even when I think about sync, CLI etc. and after using it for over a year, is that keeping such values makes the whole system confusing (and limits the user's acceptance).

¯_(ツ)_/¯

Cheers,
Marianne