Support Questions
Find answers, ask questions, and share your expertise

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

Contributor

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?

1 ACCEPTED SOLUTION

Accepted Solutions

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

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).

View solution in original post

1 REPLY 1

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

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).

View solution in original post