TIMEZONE variable should be final

[jouvin]

The broker generates a template reflecting the city location under site/ in the plenary templates, that defines the TIMEZONE variable based on the Aquilon city object. This template has 2 flaws:

• TIMEZONE variable should be declared as final as there is no point in modifying a variable reflecting the Aquilon database contents.
• The template should be declared unique to avoid that it is executed several times if included a multiple places (good for performances!).

This issue is partly related to #91 where a discussion started about an alternative to these site/ templates for defining the timezone.

[ned21]

I have found at least three instances in our code base where TIMEZONE is overriden. This might be due to a misunderstanding of how to correctly override the timezone of a host (we have some log collectors that use UTC), or because we found that too many templates assume TIMEZONE is the canonical TIMEZONE of a host and using something else didn't work properly. :-(

The template should be declared unique to avoid that it is executed several times if included a multiple places (good for performances!).

This is probably a general point about all generated non-object plenaries (we wouldn't want to special case city) so could you please make this a separate RFE?

[jouvin]

@ned21 I didn't open a separate issue about unique because after my (quick) check, all the other templates generated are structure template (except the object one). But if it is not the case, you are right!

[jouvin]

@ned21 about the main topic, the fact that the variable should be final, I tend to think that it should be the rule for every variable that reflects an Aquilon DB parameter value. I share the concerned you express often about preventing mistake done by a user that are very hard to debug. One of the possible mistake is to redefine a variable that should not... You can object me that most of the data is passed in hostdata which is part of the object configuration and cannot be declared final, AFAIK... But is is a good reason not to protect what we can protect.

May be the real solution for the problem you mentioned would be to have the possiblity to define an optional timezone parameter attached to the host, that would override the city parameters and could be passed into the hostdata (or even better to have in the hostdata a timezone information for every host for which the broker will use the host timezone if it is defined or the city timezone if it is not).

[ned21]

@jouvin I think we are almost in agreement, the variable should be final and it not being final has caused an issue that we will avoid by being more careful to set things as final when introducing new ones. :)

In practical terms, this is a backwards incompatible change though so first we need to identify the correct way for a template to override the default from the city, document that, and then update the features that are currently just overwriting TIMEZONE.

I think this is a good example of why I am sometimes reluctant to introduce new functionality, or new functionality too quickly, because removing or correcting things later can be considerable effort.