Hi Kalimulin

To be honest i never liked template nesting for a few reasons;
1) it is not that clear which items comes from where (only if you keep clicking through it till you found the parent template)
2) if you keep nesting, it's completely invisible from the frontend configuration -> hosts view as only 2 levels are presented
3) if you export templates, you must take all child templates otherwise the import is problematic. Especially this is great fun when not all names are identical as you will quickly and up with duplicate templates (with different names) and chaos starts.

That leads for us to the workflow where we do not nest templates, ever. I would rather see a full list than obfuscating it in the frontend, so in that regard i don't see any problem with this feature request / proposed change.
If we combine this with the future option of true template versioning... i get more enthusiastic. Right now we manage that via GIT, which works be always require external tools, configuration, messing around etc.

The remark about being able to merge templates is 'critical' since we cannot clone/copy LLD rules from one to another template for example, which indeed makes it time consuming.

hi,

my 2ct

• I don't see any problem at the moment with it that i can imagine .
• however things like zabbix agent should have there own template then not be in windows and linux os template
  • else we need to maintain too many parameters in different templates for the same thing
• maybe its a good idea to make some noise about this see if other ppl have use cases where nesting is needed 
• i would implement this before 7.0 this will impact many users from pre 6.0

Hi,

I can see only one downside of replacing modular design with multiple similar "flat" templates. By example, Zabbix 6.0 currently provides 6 different built-in templates for APC Smart-UPS monitoring, which are very very similar. And it is completely possible that you are using all of them on some big enterprise installation.

Now imagine that you want to add a new trigger or trigger prototype - you need to do it 6 times on each template individually. Basically, every time you want to adjust something you need to do it manually on every template which monitors your devices. And it is not very simple to compare two templates using Zabbix UI - there will be a lot of clicking.

The same is true if you are using hardware from other vendors - Cisco, HP, Mikrotik etc, it is possible that you may have even more than 10 different models from same vendor and need to maintain all items and triggers individually on every template. Modular design allowed to build device templates using smaller blocks.

But of course, i understand all problems this is causing with template import/export and versioning. As Brian mentioned before, maybe we can introduce some template merging mechanism or something like this.

@Kaspars. I 100% agree with you, updating a lot of items/triggers that should be the same will be a very big task.

This would be something that needs a workaround. Perhaps by allowing to copy over entities and updating them when copying them to targets where they already exist? Or perhaps extending mass update?

This change would be something that will break a lot of my environments and previously deployed configurations.

I use Zabbix to monitor a lot of network equipment where it's not uncommon to have overlapping SNMP OID's (for instance the most obvious one, the SNMP Interface MIB which works for Cisco, Juniper, Fortinet etc.)

By having a general Fortinet template and Cisco template on which i can nest the interface template i have a cleaner configuration instead of duplicate items all over the place which all perform the exact same way but are logically separated.
And if you take this concept of chaining templates even further you can make a very predictable template hierarchy like mentioned over here: https://github.com/q1x/zabbix-templates-30

I do understand the concerns with Template versioning and confusion on the end user.
However coming from my situation where i deployed Zabbix in multiple environments on which i fully used the nesting functionality to make predictable templates... Well i must say that i'm not keen on seeing this powerful feature being removed. Of course i am open to suggestions.

But it simply makes little sense to me from a programmers perspective to have:

• 7 different templates
• With each the exact same item
• Polling the interface description
• For each hour
• Which is the exact same OID
  For every different vendor that i manage.

Why would you duplicate so much data in the database instead of using a general interface template to link it all together?

One use case where we use template nesting a lot is in multi-tenant environments. There we are using nested templates to define/override in top level templates tenant specific macros, example, SNMP community names.
For example We have a generic Vendor Device model template, let's name it Ven_Dev_SNMP that we use as a base. Then we generate Tenant1_Ven_Dev_SNMP, Tenant2_Ven_Dev_SNMP ... etc. In each of these templates we usually had some Macros overridden. Most common case - SNMP communities, API users, sometimes also some thresholds and timers.
This simplified new device onboarding and configuration a lot, as we did not had to specify this information in a per-host basis, just adding the device to a correct template.

If template nesting will be removed - we will need to invest more effort for configuring devices or a very good tool to manage the "cloned" templates.
For such use-cases I would suggest to allow to define Macros at a host group level. This could allow us to get basically the same functionality and from my viewpoint would be even a better place to define such Tenant specific Macros.  

Other popular use case for template nesting was modular devices, example, router, router with built in AP, router with built in AP and modem etc.
Template nesting allowed us to define/manage unique information only in one place without any need to search for 10+ templates to change one thing.

My opinion is that first there should be some good template management UI created and/or implemented Macro option on Host groups as I described previously, and only then template nesting should be removed. Not vice-versa. 

Not seeing the removal of nesting with big enthusiasm myself but let's see how this evolves. I'm now in the camp which would not use the versioning feature at all, not at least with such price. 

Unsure if it was mentioned explicitly but my understanding of this feature is that existing setups with nesting will now have all the nested templates linked as 1st level templates after upgrade. It makes a big difference that they are not silently merged into parent templates but linked as individual entities. That allows to continue the use of component based templates without having to update the same items on X number of templates. It's kind of a good thing if my understanding is correct. It would at least partly solve the issues which other users here have mentioned before. Can someone from Zabbix explicitly confirm this?

Two (at least) practical problems emerge though. User has to remember which set of formerly nested templates now have to be added to newly created hosts. Formerly it was then one, now many. And the second one for upgraded instances - Autoregistration and Network discovery action operations MUST be upgraded to link all the nested templates that came with the parent template. Please ensure this during server/DB version upgrade. 

Maybe nesting can be replaced with some "template groups" that are predefined for each use case. 

Like Brian, I never really used template nesting, I always disliked the complexity for the reasons already mentioned. So I wouldn't miss it.

I always link all needed templates in parallel, and never link templates with each other. This has made template in-place upgrades, since the UUIDs and the new import GUI are available, much easier, at least for me.

One thing I really want to address, is what Patrik said: "however things like zabbix agent should have their own template then not be in windows and linux os template"

I totally agree with this. Please let me link a Windows OS template + a Zabbix agent template to a Windows host. Do not add those items to the OS templates. That is my biggest wish.

@Alex: You said: "However, this can be solved by good tooling that can merge one template into others in bulk. Such tooling must be accessible from Zabbix UI."

Can you elaborate on that, please?

Implemented in 6.4.0rc1 (master) 251249cfe83

Nested templates should not be an issue for template versioning.  Each nested template is still an existing, standalone template.  If I have a template "Foo" which has "bar" and "thing" linked to it (nested), I should only check the versioning on "Foo" "bar" and "thing"-- I should not attempt to check the version of "Foo (bar thing)".

While I can certainly still manage my systems without nested templates, having to link multiple templates individually will be a significant increase in complexity.

--John Gelnaw

We use nested templates quite a lot to avoid duplication of Items across templates e.g. many UPS, Switch etc use the same OIDs so we make modular Templates to read that data which are all linked to a Profile for that specific device make & model. Then assignment of the Profile is super easy from an automated host management POV.

starko,

Can you elaborate on that, please?

The idea is to have some template prototypes, which can be merged into a set of templates (or, say, into all templates that belong to a template group) with a single button press. This way you can maintain a common base template to share a subset of entities between specific templates. It's also worth providing a validation function so you can tell if all given templates match the common base. The details are not finalized yet so we'd appreciate any related input. This feature is set for 7.0.

Removing nested templates is a major regression in functionality.  Being able to bulk merge templates is only useful if you have a way to bulk remove template additions-- and that functionality now won't be available until 7.0 releases.

I can add a nested template to my primary linux template, and that change is propagated out to several hundred machines easily and reliably.  If i need to back that change out, I can do so, easily, and reliably.

Now, I have to either permanently alter my base template (and the tool to do this doesn't exist), or use mass update to link templates in parallel.  Neither appeals.

I agree, nestes templates can be problematic while upgrading.

But one  HAVE to use original  zabbix-provided-templates? Nope. I`ve clonned and modified all what i needed to custom tpls

IE i`ve moved mountpoint discovery to separate template. So I can add new item / trigger across whole bunch of different os`es in seconds and then, in  nested tpl`s, ajdust trigger severity for "developer windows" to notice where "producton linux" has "error" and for "generic solaris" is just turned off.

Same goes for user-macros-enabled triggers, importance of phys interface "down" in core network switch vs user access switch and so on, and so on...

Documentation (6.4) updated:

• What's new in Zabbix 6.4.0
• Upgrade notes for 6.4.0
• Zabbix features*
• Quickstart → New template
• Configuration → Templates and template groups:
  • Configuring a template
  • Linking/unlinking
  • Mass update
  • Nesting (page removed)
• Configuration → Triggers → Trigger dependencies*
• Configuration export/import → Templates
• Web interface → Frontend sections:
  • Monitoring → Hosts*
  • Reports → Availability report*
  • Data collection → Templates
  • Data collection → Hosts*
• API → Method reference*
• API → Method reference → Configuration:
  • configuration.import
  • configuration.importcompare
• API → Method reference → Template: 
  • Template object
  • template.get
  • template.create
  • template.update
  • template.massadd
  • template.massremove
  • template.massupdate
• API → Appendix 2. Changes from 6.2 to 6.4 (configuration, template)

 *only removed mention of nested/linked/inherited templates

Argh.

I.e. for Cisco devices, there are some common elements (a lot), then there are different elements per device class (ASR1K, ASR9K, switches, etc.), then there are different elements per IOS, enabled hardware or exact device functioning.

It's not always feasible to put everything into single template as differently static and discovered entities can have similar naming and stuff but different methods of obtaining (from differences in SNMP OIDs that are resolvable via macros) to requirement to use multiple OIDs at once (memory counters, some interface counters, VPLS, etc.), to even requirements to use console.

Without template nesting this becomes a hell. So only one question here: WHY? 'Import/export version tracking' does not justify that. Just document disabling and disable this version tracking for templates that use nesting and those who want nesting will know they sacrifice some unnecessary feature in order to get the crucial one.

Hello,

we also use nesting in our company ...   I follow the rules that never repeat same item twice.. This would cause problem to us too migrate...

What about just allow to have 2 level of nesting... And the first top level will be just some special template without possibility to have own item, triggers etc... This template will be used just for join all the sub-templates into one piece which then can be assigned to the hosts. Maybe it would be also fine to allow some change small changes like disable/enable item/trigger, change severity and add user macros.

so for example:

cisco nexus 9000 series by SNMP (will be empty template)

which have modules assinged/linked as follow:

• cisco nexus power supply by SNMP
• cisco nexus inventory by SNMP
• cisco nexus fans by SNMP
• cisco interfaces by SNMP
• ...

This would fit to our need

I think this concept can help lot of people to migrate to new system... I think most of use was just use 2 level of nesting....

Thanks in advance

If we get two levels, we may as well get infinite levels again.
This change completely ignores the advice given by Zabbix's own doco: https://www.zabbix.com/documentation/guidelines/en/thosts/key_principles#modularity-and-scope
How can we make modular templates without nesting? Trying to get dozen's of templates assigned correctly across 25,000 Hosts is a nightmare I don't want to consider lightly.

Currently I have to only assign Profile <<VENDOR>> <<MODEL>>, this profile is linked to the modular templates that collect information related to that model.

So after my comment on the 1st of januari this year and some feedback from other users in this post stating that their whole Zabbix template hierarchy depends on template linkage, is this still something that the Zabbix team wants to remove?

In an ideal world i would see both versioning and linked templates working in Zabbix.

A clear example of this would be the requirements file in Python git projects, which would state the versions of other relying Python projects. Even though the project itself can be updated and have multiple version numbers.

Would it be possible to implement a seperate Zabbix object type perhaps 'template collections' or 'template profiles' where these are just simply lists of templates.

These lists of templates would be assigned to hosts effectively separating these from templates and changing the way the templates end up being assigned to hosts.

This would enable the flattening of templates and the automatic management of templates while still enabling the reuse of templates like the community currently do (including Zabbix official templates).

If the above is not possible would there be an approach that will facilitate template nesting along with the ability to automatically manage official templates and othe use cases mentioned in the description? (See below for suggestions)

Template nesting as mentioned is a historic value adding feature that promotes well designed/structured templates that are reusable along with reduction of the complexity/number of templates linked to hosts.

Removing template nesting will require additional effort either when assigning templates or duplicating items that may exist on multiple templates. It will increase the risk of these duplicate items from being out of sync if the duplicate items are updated in any way.

If the automatic template management is required within Zabbix could you do one of or a combination of the following which will allow both nested templates and automatic template management:

• Differentiate between Zabbix official and 'community/custom' templates.

• The ability for users to enable/disable template automatic management for specific templates as the user may want to make changes to Zabbix official templates as required.

• The uuids of official templates are known so you could have a method where the user can initiate a remote template diff of the configured vs remote template for the specific Zabbix version. Note that template version and vendor does fiekds not imply the template configuration is what it should be. This may then progress to 'import' if differences are detected and the user selects whether they want to import.

• the ability for users to select which templates are auto-managed (which maybe a good thing as they may not want to automatically manage templates)

It may be understandable that official zabbix templates are managed the way you see fit which may include automatically updating them during updates for example.

However this more than likely won't be the case for 'community/custom' templates unless in the future zabbix templates end up in a managed repository like python pips, ruby gems, puppet modules where the same approaches as above could be used...

Could there be a need for a separate online template repository like I have mentioned above similar to how pips,gems and modules are managed and distributed?

Those repositories seem to have worked well within the industry?

This way a template would have a version itself, zabbix supported version and requirements (nested templates etc) that could be used when automatically managing them.

Twan K mentions perhaps using similar approaches to python pips where the import would look for the nested template requirements and import them aswell.

Please please please don't remove the ability to nest templates....

Alex Kalimulin,

With the possibility of this 'template prototype' concept with the possibility of merging into templates...

We would be in the position if that template prototype changes in any way shape or form the templates where we merged it into would not change again as its not linked.

Even if you re-merged and the things that define the templates objects uniqueness like graph name, item key may be updated in the template prototypes; therefore orphaned/old/stale original objects would remain in the template leaving a messy template contain old and new things...

Hence were back at nested templates where this is not an issue.

Regards

Is this the final decision? We should understand, because it would be just hell to change the structure from nested templates to ... this.

This is a surprising change to see in the release notes, and this will likely hold us back in 6.2 for some time as a result

One of our key use cases is creating a template for each specific model of device, linking in the same core template but then adjusting the macros to match its specific requirements (eg. maximum PoE budget of device etc)

We also relied on key templates (eg. ICMP/Generic SNMP/Interfaces) that allowed us to easily centrally update all dependent templates without worrying about if someone forgot to tick X template in a mass update

Exactly... We also use one module template for ICMP and another for reporting staff ... and all those templates are linked to nearly all other templates.... 

And even we use same template for multiple customer with different threshold... after this change we have to have lots of clone of same template... or we have to do it on host level which is also BAD idea....

Please consider one TOP level template which will be only for joining other templates and with possibility to add user macros there... 

Thanks

As a consequence, please implement the solution described by James Cook: Template Collections. A collection can contain other templates, tags and macros, but not its own entities. Everything else is practically unusable.

The change already causes enormous additional work and countless duplicate items. That was Zabbix's most outstanding feature: modularity. Now it is gone. Especially if you want to make a change to an elementary item/trigger now, you have to manually apply this change to all other cloned templates. With the number of templates, the probability of forgetting something increases enormously (e.g. ICMP, SNMP interfaces, etc.). What remains can be inconsistencies in forgotten and untouched templates.

So for such a serious change, the UI must at least provide outstanding capabilities to minimize the manual effort in some way. Maybe mass updates based on criteria/conditions or something similar. At the moment I can't imagine how well this will work in the future. But template collections would be a good tradeoff after all.

Just to add to it, macros and just inheritance to apply different stuff is not the only problem. This can be partially avoided host level, just increasing amount of work to apply stuff and increasing error probability for people with no automation.

But in i.e. my case, inheriting templates have a tendency to extend stuff basing on inherited templates items. This cannot be easily emulated host level because we need to have inherited template items to add them to dependent items and triggers in the template inheriting. And the level of such inheritance can easily include 3-4 steps. Moving this host level is just impossible, it will require a tremendous amount of template cloning and then tracking changes through all the cloned templates...

Collections will also not solve this as it's exactly what I have: templates basing on other templates ARE having their own items, triggers and even dependent-item LLDs based on the inherited stuff.

Alexey,

The idea of template collections was only thinking about a compromise which would only help with the reuse and assignment of templates.

WIth our instance we used to have three template levels being Roles -> Profiles -> Templates and we flattened this to just Profiles and Templates and assign profiles to hosts, which we saw a massive performance increase in many areas of the frontend.

So the suggestion of limiting the depth of template inheritance would help with performance. Perhaps they need to look at having a seperste object like I mention which would facilitate exactly what we need and hosts can either be assigned templates or profiles (however they may as well just keep nested templates).

It's pretty obvious that nested templates is the most functional, flexible and widely used approach that simply just works.

From the developers point of view, performance and complexity definately takes a hit with nested templates.

However since the functionality provides so much value to people that design well structured and reusable templates for large scale environments I would like to think they reinstate this.

They should perhaos think about the problems nested templates solves and perhaps work out a method that solves these problems along with increasing the performance and decreasing the complexity.

I do see this issue only has 5 votes yet 38 people watching this which implies not many people want to remove nested templates and it impacts more people as a result.

Fingers crossed.....

Is this the final decision? We should understand, because it would be just hell to change the structure from nested templates to ... this.

Given the feedback in this ticket and in other channels, this decision is currently under review.

To the point, James made about watchers.

I'm a watcher on this, and the removal of nested templates is a serious issue for us and means we'd be unlikely to upgrade any time soon.

We heavily use nested templates (usually just one level) and subscribe to the D-R-Y (Don't Repeat Yourself) approach for all the reasons others have detailed.

Much of what I think about this has already been said, but it cannot be stressed enough how severly this negatively impacts zabbix as a monitoring platform.

It seems like the driving factor for this is template versioning, so I assume you have somehow weighted the pros of zabbix native versioning against the cons of removing template nesting and somehow have come up with versioning being more valuable?

The problem with this rationale is I can't imagine any larger organization not suffering from this, since the amount of duplicated template configuration creates an administrative nightmare in having to update identical configuration on a large number of templates instead of re-using template modules. Not only that but it also introuduces a uncertainty when it comes to template integrity and monitoring reliability.

Of the arguments listed as improvements to justify this,  the versioning seems like the only real upside to us as end users.
"Simpler server-side and frontend code" is not going to make us happier, "Simpler user interface" is a mariginal improvement at best and "Better performance" I guess can be achived any way if one choose not to net templates, which is obviously a fine choise for those who prefer that.

The fact that "Zabbix ships all standard templates flattened" means nothing when end users are not subscribing to this way of working.

The disadvantage of losing maintainability is also hugely understimated. For us it would make templates very hard to maintain as some of our template modules are linked to 20+ unique host type templates.

The description also states that "this can be solved by good tooling that can merge one template into others in bulk. Such tooling must be accessible from Zabbix UI".

This is nice, but where is the implementation? It's a bit concerning that this feature is not developed in conjunction with such a huge breaking change.
How can we be assured that this tooling will actually solve the administration issues of common templates?

I do appreciate all the feedback we received after the Zabbix 6.4.0rc1. It made us rethink the original solution. We have been working on a better one last two weeks. The idea is to figure out how the existing nesting and template versioning may coexist. Our initial assumption was that it is not possible.

While it is early to tell that we came to a final decision, we are very close. I am optimistic about it. Stay tuned!

We're a bit surprised how this kind of change, without proper announcement (Roadmap?) might end up in a update.

In my company it is a breaking change - we are working heavily with the nesting. You can argue with the pro and cons but you can't argue that we as the customer are forced either to update and break our integrations or postpone the update and loose support.

It would make more sense to put this kind of changes to the LTS versions.

To setup a new CI/CD pipeline in a enterprise environment is not so straight forward and can't be done on a short notice.

Even if we flatten the templates, and provide them trough a repository (git/svn or whatever, pushing our source template through an template engine to have the same features as nesting...) in a new pipeline I do see some problems:

E.G. Zabbix provides new OOB Template version 1.0.0. We as the customer adop the version in the UI. Zabbix Provides new OOB Version 1.0.1 we update the template and loose all our changes. So we end up at least copying it once to be safe (so we still will end up running stoneaged templates - even if the intend was to mitigate this).

Also, how do you want to adopt a single template to different environments? Again we need to copy and maintain multiple copies (or we use a Template-Engine that replaces the nesting). This not very failsafe nor convinent.

This might be all fine and dandy as long you realy live the theory of infrastructure as a code. A soon as user want change something the UI you stumble upon:

ZBXNEXT-1111

Which means if some one updates/adopts/extends the template in the UI the version will stay the same. So any automated pipeline needs to again compare the templates because the version field is not comparable.

A (very unrealistic) possibilty would be to disable all ui interactions with templates, or as an idea to extend the version field with some self incrementing value. But that doesn't remove the (negativ) impact on integrations.

Food for thought...

The problems that need solving in this issue and the versioning issue (zbx-1111) are:

1. ability to identify templates by vendor, version.

2. ability to confirm whether official/custom templates differ in a live running zabbix server and a template source (local file, Web file).

3. ability to define template objects in a source that can be included in templates; when objects are changed in or deleted from the source they will be reflected in templates that include them.

4. flattening templates to improve performance and simplification.

I believe 1 & 2 can be solved with utilising the existing vendor and version fields along with adding 'source' information.

This data would be then used to compare the template from the source to the live zabbix server.

It should use the same functionality when importing them via the fronted in which it shows the differences or whether it is identical.

This would allow the user to determine which templates may need importing to ensure the correct template configuration is in place as per the source.

The actual version maybe irrelevant as we're actually trying to determine whether the template configuration is different compared to a source and like people have said content may be different regardless of what version label is there.

This is why the source is probably the most important piece of information here.

A few rules when comparing the source and live templates:

• If the source template uuid does not match the live template uuid then it can not be compared compared as it is different.

• If the source is not specified then it can not be compared (I.e. make it optional)

• If the source is spevified but does not exist then it can not be compared.

I believe 3 & 4 can be solved with template prototypes where its pretty much the same as template linking, however you have a seperate object called template prototypes which are 'imported' (fully duplicated) into templates and the template objects have a source I'd representing the original object id from the template prototype.

If an object exists in a template that has a template prototype source I'd then certain attributes can not be changed depending on the object type (I.e. an item with a source I'd would NOT be able to change the item key, but may be able to change the item interval - much like how it works at the moment with the ability to change nested template items).

If a change is made to a template prototype then this change is reflected in any template object where the source id matches.

If a deletion is made of a template prototype then this will also be deleted in the template where the source id matches.

Templates will never allow an object with a source I'd that does not exist in a template prototype and should be enforced at the database schema layer.

I am aware that this importing will have duplicate configurations in templates, however the most important thing is there is a way to manage the duplication from a single source I.e. template prototype and source id.

When dealing with the templates the configuration would be loaded from the templates themselves and not the template prototypes as all the required information is duplicated in the template.

As a result there would be no nested templates and performance would be improved as things like latest data and host object configuration would come from multiple but single level templates.

I think the above are some possible ways to go about making a usable solution that solves the required problems.

I'll add another rather harsh 5 cents here.

As I see it, versioning only has meaning for bundled Zabbix templates and those who use it.

Those who design multiservice templates maintain them themselves and usually use a centralized Zabbix database with proxies to cope with all the load. So no need for versioning or it is outside of Zabbix in the design sheets and updates.

Those who maintain templates 'as code' work with the database/API themselves and update templates using automation. So again, the versioning is outside of Zabbix.

Thus, the effort to prioritize versioning and extend it beyond bundled set seems completely meaningless and it can be only left to what requires it. Specifically, flat bundled templates.

Reverted in 6.4.0rc2 e2287b52ae1

I do appreciate all the feedback we received after the Zabbix 6.4.0rc1. It made us rethink the original decision to drop the support of template nesting. Now the functionality is back to Zabbix 6.4, and we have no plans to remove it!

I clearly see that we have underestimated the importance of the use cases backed by template nesting, primarily when it is used as tooling for easier management of templates and macros. At some point we have realized that the nesting might co-exist with template versioning if we skip dependency management altogether and keep template version intact regardless of template linkage.

Now it sounds like a logical solution but believe me it took hard work and numerous discussions to reach this point.

I am extremely delighted with the outcome! Thanks so much everyone. 👍

Hi Alexei (and team),

I'm so glad to see this being reverted. I really like Zabbix for its functionality and seeing the company being critical and rethinking about its own decisions and even reverting back is something that will make us use Zabbix with way more confidence. Respect and thanks for the communication.

> I am extremely delighted with the outcome!

Same here. Thanks for keeping it intact, it will save me a lot of lifespan

Thank you all again for your feedback and thoughts about template versioning and nesting! Just to build on what Alexei said:

There are two groups of users expressing opposite views on the subject and we did anticipate that. But to be honest, without any firm data (as Zabbix does not collect any usage stats) we underestimated the importance of nesting for those power users who invested considerable time resources and effort into building their workflows that rely on template composition.

Our initial assumption was that versioning and nesting are two mutually exclusive concepts that can not coexist together, because as soon as you inherit one template from another you need to maintain the sequence of the versions participating in the graph. Things may get even uglier when you deal with multiple inheritance at multiple levels. However we look at this problem, there is no good solution without full-fledged dependency management, which is hard to get right and should not be the focus of a monitoring system.

That being said, there is another angle to look at the versions and we decided to exercise this view. Version only building blocks, not the entire building. This changes nothing for Zabbix standard templates (which are and will remain flat) because these are already self-contained. If you want to track versions for your own templates just assign versions to the smallest common denominator. But if you want to version the entire umbrella template, Zabbix will not prohibit you from doing that. Just remember you're versioning the umbrella, not what's underneath.

In other words, we are still committed to flat templates and will continue promoting this approach in our standard templates as the simplest and the most straightforward way. But at the same time, we will continue supporting template nesting without any plans to abandon it in the future.

Documentation (6.4) reverted.

Functionality was reverted in https://www.zabbix.com/rn/rn6.4.0rc2

Just to summarize, upgrade from any version prior to 6.4.0rc1:

As you can see, it's not recommended to upgrade to rc1 if you have nested templates. Upgrade to rc2 or later.

NB! Going flat is unrecoverable operation.

@dimir Maybe it would be wise to revoke 6.4.0rc1 totally so people experimenting won't hit the flattening?

Alex/AT packages are already removed from https://repo.zabbix.com .