Hi @Sampath Kumar, Some changes in Ambari 2.6.0 have been introduced that modify the way that install repository overrides are setup. Please see this link that describes the new process for setting up local repos: https://docs.hortonworks.com/HDPDocuments/Ambari-2.6.0.0/bk_ambari-release-notes/content/ambari_relnotes-2.6.0.0-behavioral-changes.html Hope this helps. Thanks, Bob ... View more

Hi @Anshuman Mehta, 1. That's correct, Blueprints are only for the initial install of a cluster. 2. Incremental changes cannot be applied to a Blueprint after a cluster has been created. A Blueprint, once posted to the REST APIs, is considered a static document. Updating a Blueprint after a cluster has already been created with that Blueprint will have no affect on the existing cluster. 3. Yes, REST calls would need to be made in order to update the configuration for the existing cluster. 4. Generally, the Blueprint export feature can be used to take a snapshot of the existing cluster ( components and configuration), and then re-use that Blueprint to create a new cluster, perhaps making some modifications prior to deploying the new cluster. It is also worth noting that Blueprint exports can be taken on clusters that were created with the Ambari UI, and this can provide a way to reproduce an existing cluster, even if it was not originally created with Blueprints. While not directly related to your question, I thought it would be useful to mention that Blueprints integration with the Ambari StackAdvisor was introduced in Ambari 2.2.0, and can be used to apply Ambari's configuration recommendations to the Blueprint specified. Here's the link that provides more information on that topic: https://cwiki.apache.org/confluence/display/AMBARI/Blueprints#Blueprints-ClusterCreationTemplateStructure Thanks, Bob ... View more

Hi @Ali, There is a way to have the Blueprints processor apply the Ambari Server recommendations for configuration for various services. In Ambari 2.2.0, Blueprints was updated to provide integration with the StackAdvisor/Recommendations engine. Basically, adding some configuration in the cluster creation template will instruct the Blueprints processor to apply the output of the recommendations engine. There are various strategies that can be applied, based on the desired outcome. By default, the strategy is "NEVER_APPLY", which means that recommendations are not applied by default. This was done to ensure backwards compatibility, as the Blueprints processor preceded the StackAdvisor implementation in Ambari. Here's a link to the configuration you'll need to add to your cluster creation template if you'd like to have Blueprints apply the recommendations automatically: https://cwiki.apache.org/confluence/display/AMBARI/Blueprints#Blueprints-ClusterCreationTemplateStructure The "config_recommendation_strategy" property needs to be added to the cluster creation template, and set to one of the supported strategies. This should allow you to make your Blueprint smaller and more portable, since the recommended values do not need to be set, unless you prefer to override the values set by the recommendations engine. Hope this helps. Thanks, Bob ... View more

Hi @Kirk DeMumbrane, Can you post what version of Ambari you're using? In the LogSearch Technical Preview, which was introduced in Ambari 2.4, there was a bug that would keep the Ambari integration layer (which displays the tail log of components in Ambari itself) from working properly when SSL was enabled. This issue was resolved in Ambari 2.5: https://issues.apache.org/jira/browse/AMBARI-19104 If you are working with Ambari 2.5, then you can probably just update the "logsearch_ui_protocol" in the "logsearch-env" configuration type to be "https", restart ambari-server, and the connection between ambari-server and the LogSearch Portal should work properly at that point, and I would expect that the error logs in ambari-server.log would stop occurring. Regarding the "No Data Available" message, it is possible that the existing logging data in your cluster has expired, and been removed from the Solr data store. Typically, Solr expires logging data from LogSearch after 7 days, unless this has been explicitly configured. Hope this helps! Bob ... View more

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 more

HI @Vladislav Falfushinsky, The Blueprints processor does validate dependencies in a Blueprint, but at a different level than the UI. The Ambari Web UI will validate at the service level (HDFS, Yarn, etc), while the Blueprint validates the dependencies between components ("NAMENODE", "YARN_RESOURCEMANAGER", etc). This is due to the fact that Blueprints operate only on components, and not at the service level. This is why you see slightly different validation behavior in either deployment mode. The Blueprint processor validates a Blueprint's components for dependencies using the dependencies defined in the stack definition for that service or set of components. There are two possible reasons why you might not see the dependencies being verified: 1. If you've turned off validation while POST-ing the Blueprint, then no component-level validation will occur. This validation is on by default, and is controlled by a query parameter that can be set when POST-ing the Blueprint: https://cwiki.apache.org/confluence/display/AMBARI/Blueprints#Blueprints-BlueprintUsageOverview 2. If the stack definitions for the services in your Blueprint do not correctly specify dependencies between components, then validation may not occur, as the Blueprint validation process is driven by the stack data. Hope this helps. ... View more