Support Questions

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

Ambari blueprints export problems

avatar
Expert Contributor

Dear community,

I`ve successfully imported blueprint into the cluster, but when I decided to export it back I had received totally different blueprint with some other ordering of resources, names of host groups and some other issues. That makes some problem in verification of blueprints that I have under git and ones that are actually deployed to servers.

Best regards,

Vladislav

1 ACCEPTED SOLUTION

avatar
Expert Contributor

Hi @Vladislav Falfushinsky,

It is expected behavior that you would receive a Blueprint with some differences from the original Blueprint that you created the cluster with.

It's important to note that the Blueprint "export" feature works for any cluster deployed by Ambari, including those created via the Ambari Web UI Wizard. This means that the exported Blueprint will give you the current state of the running cluster, whether or not this cluster was created with a Blueprint originally. This is why the host group names are different, since the Blueprint exporter needs to generate names automatically.

The configuration may be different as well. There are a few reasons for this: 1. Configuration may have changed between the time the Blueprint cluster was deployed and before the export was taken, 2. The Blueprint export will include all configuration in the current cluster in the Blueprint. This was implemented in this way in order to give a complete snapshot of the cluster at the time of export. This of course will differ from the original Blueprint (if one was used), since likely only configuration overrides are included in the Blueprint.

Another possible area of difference is that Blueprints will sometimes add dependency components (typically client components) to a Blueprint deployment at Cluster creation time. If validate_topology is set to "false" then these additions won't occur, but they are turned on by default.

If you need to see the Blueprint you used to create a cluster, you can always access it via the REST "blueprints/$BLUEPRINT_NAME" resource, where "$BLUEPRINT_NAME" is the name of your Blueprint.

Comparing the Blueprint you originally used with with an exported one from the same cluster at a later point in time may not be feasible.

Hope this helps.

Bob

View solution in original post

2 REPLIES 2

avatar
Expert Contributor

Hi @Vladislav Falfushinsky,

It is expected behavior that you would receive a Blueprint with some differences from the original Blueprint that you created the cluster with.

It's important to note that the Blueprint "export" feature works for any cluster deployed by Ambari, including those created via the Ambari Web UI Wizard. This means that the exported Blueprint will give you the current state of the running cluster, whether or not this cluster was created with a Blueprint originally. This is why the host group names are different, since the Blueprint exporter needs to generate names automatically.

The configuration may be different as well. There are a few reasons for this: 1. Configuration may have changed between the time the Blueprint cluster was deployed and before the export was taken, 2. The Blueprint export will include all configuration in the current cluster in the Blueprint. This was implemented in this way in order to give a complete snapshot of the cluster at the time of export. This of course will differ from the original Blueprint (if one was used), since likely only configuration overrides are included in the Blueprint.

Another possible area of difference is that Blueprints will sometimes add dependency components (typically client components) to a Blueprint deployment at Cluster creation time. If validate_topology is set to "false" then these additions won't occur, but they are turned on by default.

If you need to see the Blueprint you used to create a cluster, you can always access it via the REST "blueprints/$BLUEPRINT_NAME" resource, where "$BLUEPRINT_NAME" is the name of your Blueprint.

Comparing the Blueprint you originally used with with an exported one from the same cluster at a later point in time may not be feasible.

Hope this helps.

Bob

avatar
Expert Contributor

Thanks @rnettleton.

In my variant I am deploying cluster only via blueprint and no additional configuration is done via Ambari UI. It seems I should access blueprint via "blueprints/$BLUEPRINT_NAME" for blueprint validation that I have in git.