Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

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

avatar
Rising Star

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

avatar

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

avatar

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