Member since
10-02-2015
50
Posts
12
Kudos Received
11
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1411 | 01-03-2018 04:12 PM | |
1121 | 01-03-2018 04:07 PM | |
1576 | 07-20-2017 02:18 PM | |
1866 | 06-22-2017 09:33 PM | |
1118 | 03-20-2017 02:57 PM |
01-03-2018
04:12 PM
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
01-03-2018
04:07 PM
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
07-20-2017
02:18 PM
1 Kudo
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
06-26-2017
03:26 PM
Hi @Kirk DeMumbrane, Glad this information was useful. If this resolves your problem, can you please accept this answer? Thanks, Bob
... View more
06-22-2017
09:33 PM
1 Kudo
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
04-13-2017
06:35 PM
Hi @Theyaa Matti, Depending upon the services you have deployed in your cluster, the audit logs will generally be written to for service-specific actions that occur (HDFS write, HDFS read, Ambari REST calls, etc). Are you looking for a specific service's audit logs? Please note that not all services write audit logs. What version of Ambari are you using? Hope this helps, Bob
... View more
03-20-2017
02:57 PM
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
03-03-2017
04:38 PM
Hi @christophe menichetti, As @Predrag Monodic mentioned, you can use Blueprints for non-UI based installs. Unfortunately, the UI Wizard will not allow you to generate a Blueprint and Cluster Creation template after you gone through all the screens. The simplest way to generate a Blueprint to start with is to try the following: 1. On a local VM cluster for testing (vagrant, docker, etc), create a cluster that has the services, components, and configuration that you are interested in deploying in your production cluster. 2. Use the UI to deploy this local cluster, going through all the normal screens in the wizard. 3. You can then export the Blueprint from this running cluster. This REST call will generate a Blueprint based on the currently-running cluster you setup in Step #2. 4. Save this Blueprint, and customize it as necessary. 5. Create a Cluster Creation Template that matches hostnames to the host groups from the exported Blueprint. Please note that you may want to manually rename the host groups in the exported Blueprint, as they are generated using a "host_group_n" convention, which may not be useful for documenting your particular cluster. You can check out the following link on the Blueprints wiki to see how to make the REST call to export the Blueprint from a running cluster: https://cwiki.apache.org/confluence/display/AMBARI/Blueprints#Blueprints-APIResourcesandSyntax Hope this helps!
... View more
02-15-2017
04:30 PM
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
02-09-2017
06:34 PM
Hi @Vladislav Falfushinsky, Apart from the validation routines that you mentioned at the Blueprint and Cluster Creation Template levels, there isn't really much support for a "dry run" deployment, although that would be a good idea for a future release, since it would assist in some types of testing while developing a new Blueprint. I'm not sure what version of Ambari is being used in your case, but I'll assume Ambari 2.4 for now. In Ambari 2.1.0, the Blueprints deployment mechanism was refactored to allow for a more dynamic deployment model, such that hosts could join the cluster after the Blueprint deployment started, and the Blueprints processor will react to this and update the configuration accordingly. I'm not sure how you created the Blueprint, but if you exported a Blueprint from a particular cluster, and are trying to recreate the cluster on a slightly different topology, or using a different set of services, that may be a part of the problem. Can you post the portion of the ambari-server.log that shows the error you mentioned? The host group involved in the failure should be mentioned in the log message. Can you also post the Blueprint you're trying to deploy? It may be that your Blueprint references a host group that is not defined in the Blueprint, or perhaps a "%HOSTGROUP%" token is being used for a component that is not included in any host groups in your Blueprint. Hope this helps.
... View more