How to update/modify a blueprint once the cluster is created?

[#1]

I'm using blueprints to automate ambari installation. It is working fine for the initial setup, but as the cluster changes, how do I update the blueprint? There doesn't seem to be a way to apply a update or new blueprint to an existing cluster.

[#2]

@Raghu Udiyar the blueprint is managed by ambari. So if you are changing your cluster, the blueprint should reflect the change. for example I just added storm to my cluster. I did a fetch on the blueprint and the storm now exist in the blueprint. Does that help or did i misunderstand your questions. cheers

[#3]

@Sunile Manjee basically I want to only manage the blueprint, and not use the Ambari UI for cluster setup. Any service/component changes are only done in the blueprint, and then pushed to Ambari. In this way my service/component configuration and layout state is always in the blueprint.

It seems like blueprint is designed only for the initial cluster configuration. But, any changes after that have to be done through the UI, or the REST API. IMO this reduces the usefulness of using blueprints in production environments. If blueprint supported incremental changes, I'll have a single workflow to introduce changes to Ambari, and also have latest state stored in the blueprint.

[#4]

@Raghu Udiyar you can manage your cluster through puppet/chef which would make call to ambari rest api for changes. this is used a ton in the field with success. I believe you are suggest simply upload new blueprint and cluster should detect changes and perform. its an interested idea. however the current methods work very well with success.

[#5]

@Sunile Manjee I was assuming blueprint as a declarative encapsulation over the rest api's. The api's are verbose; I'll need to take care of all state changes there. I have to cycle through these state changes manually (INIT, INSTALLED, STARTED, etc). Also, do they take care of HA when I add components? I'll have to query and check the state of each host to ensure idempotency. Blueprints are good to hide this complexity, and leverage the logic already built into Ambari. Does this make sense?

[#6 · Accepted solution]

Hi @Raghu Udiyar,

While the Blueprint POST-ed to Ambari will not change as the state of a cluster changes, you can consider "exporting" a Blueprint from a live cluster. After a set of changes to the cluster (Config changes, services added/deleted, etc), exporting the Blueprint will provide a Blueprint that describes the current state of the cluster, which would be different than the original Blueprint used to create the cluster.

Based on what I've seen in this issue, it looks like you could use the Blueprint export feature to maintain a Blueprint of the current changes, so that you could always recreate this cluster layout on different hardware if necessary.

Here's a link to the Blueprints documentation on Blueprint exports:

https://cwiki.apache.org/confluence/display/AMBARI/Blueprints#Blueprints-APIResourcesandSyntax

Blueprints can also be used to create HA-based clusters from scratch. That feature has been present since Ambari 2.0, and a link to more documentation on this can be found at:

https://cwiki.apache.org/confluence/display/AMBARI/Blueprint+Support+for+HA+Clusters

[#7]

@rnettleton Yes, this is how we are currently maintaining the cluster configuration, and its working well so far. I was thinking of using it for incremental changes as well. That is, to use blueprint interface to add/remove components, and ambari then pushes that state, so I don't need to use the UI. But, our actual use case is for backup and ability to recreate clusters, which is satisfied with current blueprint functionality.