What is the best way to upgrade Ambari blueprints for an Ambari upgrade?

[#1]

I use a detailed Ambari blueprint to install a HDP cluster. When a new version of Ambari is released my blueprint upgrade technique is to manually install a similar cluster, export the new blueprint, diff old and new, then update the new blueprint for anything missed.

This process is time consuming and prone to error. Is there a better way to maintain blueprints across Ambari versions?

[#2 · Accepted solution]

Sadly, no. In general, the smaller the blueprint the lesser the chances of breaking compatibility. Let me explain a bit as its not an intention to break backward compatibility. At a very high level, blueprint contains a) components and their layout, b) config settings that are Ambari influenced, c) config settings that are stack influenced, and d) templates for *-env/sh files etc. In general, * (a) remains backward compatible even through major releases.

* (b) and (c) should remain backward compatible unless some config cleanup is performed e.g. created new configs for env/log4j files, cleaned up how heap sizes are specified - rare * (d) includes scripts - these can go through bug fixes for any release

So if you have a blueprint with primarily (a) and only the configs for which you want to over-write the default it should remain backward compatible. The biggest hurdle you can run into is that when you export a blueprint it does not export a minimal blueprint - rather a blueprint with all sections including (d).