@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. ... View more

@Ana Gillan We are seeing this error on HDP 2.2.9 when we run to storm hive bolts in parallel. The error goes away when a single bolt is used. Is this expected behaviour? ... View more

Ok, Thanks! I'm on HDP 2.2.9, so this should be fixed then. The change log has Apache Jira for some, but not all of the change logs, having Apache Jira ids would really help. ... View more

@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? ... View more

@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. ... View more