Ambari 2.6 introduces the following change in behavior as compared to previous Ambari versions:

Ambari Blueprint Stack & Repository Version Behavior Change

In Ambari 2.6.0, the Ambari upgrade framework has been updated to set the stage for automated patch application and management. This feature will be available in future versions of Ambari. Due to these changes, the logic used to identify the repo version to be used during a Blueprint install has changed. This change only impacts Blueprint deployments. To ensure that Ambari uses the intended version of the repository for your install it’s recommended first to register the desired version of HDP using a VDF file, and second to specify the version in your Blueprint explicitly.

If you do not register a VDF file and specify the repository_version_id, or repository_version during blueprint creation, Ambari uses the default repository version defined in the stack versions included with Ambari 2.6.0. Ambari identifies the default repository version using the hdp_urlinfo.json’s "latest-vdf" if that is available and defined. Otherwise, Ambari uses the stack metainfo.xml to identify the default repository version based on the stack_version defined in your Blueprint.

To register a VDF file and specify the repository_version_id, or repository_version during blueprint creation:

Registering a VDF file

The version_definitions API should be used when registering a VDF file. The example command below shows how to register the 2.6.3.0-235 version of HDP using the publicly available VDF file:

curl -v -k -u admin:admin -H "X-Requested-By:ambari" -X POST
http://ambari.server:8080/api/v1/version_definitions \
-d '{
  "VersionDefinition": {
   "version_url":
"http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.6.3.0/HDP-2.6.3.0-235.xml"
    }
  }'

If the publicly available VDF file is not reachable from your installation, you can use a VDF file that has been downloaded to the local file system of the Ambari Server:

>curl -v -k -u admin:admin -H "X-Requested-By:ambari" -X POST
http://ambari.server:8080/api/v1/version_definitions \
-d '{
 "VersionDefinition": {
   "version_url": "file:/tmp/HDP-2.6.3.0-235.xml"
 }
}'

The response from this request will give you a unique id for the version that has been registered. For example:

{
  "resources" : [
    {
      "href" :
"http://ambari.server:8080/api/v1/version_definitions/51",
       "VersionDefinition" : {
        "id" : 51,
        "stack_name" : "HDP",
        "stack_version" : "2.6"
      }
   }
 ]
}        

Specifying Registered Versions in Blueprint Cluster Creation

When using a Blueprint, to ensure the cluster install uses the version referenced in the previously registered VDF, either reference the id, or the specific version in the cluster creation request.

Blueprint repository version reference by id:

...
{
  "blueprint": "<blueprint name>",
  "repository_version_id": 1,
  "default_password": "password",
  "host_groups": [ ... ]
}
...

Blueprint repository version reference by version:

...
{
  "blueprint": "<blueprint name>",
  "repository_version": "2.6.3.0-235",
  "default_password": "password",
  "host_groups": [ ... ]
}

...

Specifying registered versions when pre-installing from local yum repositories

A local repository configured from a yum repository is not "managed" by Ambari.

With Ambari 2.6, a custom yum repo file name (HDP-2.x.x.x.repo) does not have to match the Ambari yum repo file name (ambari-hdp-1.repo), but the format of the repo names in the yum repo file changes. For example, the following repo name format is no longer recognized by Ambari,

 [HDP-2.6.4.0]
 name=HDP Version - HDP-2.6.4.0-91

and has to be changed to the repo name format which Ambari 2.6.x now expects,

 [HDP-2.6-repo-1]
 name=HDP-2.6-repo-1 

and which the Ambari install wizard local repo option uses when it creates the ambari-hdp-1.repo file.

IF you are pre-installing HDP packages using a local yum repository, make sure that the local repository name is recognized by Ambari-2.6.x.