ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juanjo Marron <>
Subject Re: Managing stack_version on Ambari 2.4 code
Date Wed, 27 Jul 2016 00:02:50 GMT
 Hi Alejandro,
 Thanks a lot for your reply,
  I run a basic test just with Zookeeper in one node cluster. It is installed properly but
when trying to add new services,  the restAPI call to obtain stack_services filtering by
state=CURRENT is of course failing (state is INIT)

  Due to this issue I started my investigation based on versions issues and I got the details
in previous email:
  - Components installed with unknown version
  - missing current_version in command-xx.json
  - missing stack_version in structured-out-XX.json

The output of the DB queries are:  

 Just one repo version with version 4.3
 ambari=> SELECT repo_version_id, version FROM repo_version;
 repo_version_id | version
               1 | 4.3
 The right repo_version is used, the cluster never transitioned to CURRENT
 ambari=> SELECT * FROM cluster_version;
 id | repo_version_id | cluster_id | state |  start_time   |   end_time    | user_name
  1 |               1 |          2 | INIT  | 1469549875153 | 1469549875153
| admin
(1 row)

Just a ZK components installed and versions are unknown

ambari=> SELECT h.host_name, hcs.service_name, hcs.component_name, hcs.version FROM
ambari-> hostcomponentstate hcs JOIN hosts h ON hcs.host_id = h.host_id ORDER BY
ambari-> hcs.version, hcs.service_name, hcs.component_name, h.host_name;
      host_name      | service_name |  component_name  | version
---------------------+--------------+------------------+--------- | ZOOKEEPER    | ZOOKEEPER_CLIENT | UNKNOWN | ZOOKEEPER    | ZOOKEEPER_SERVER | UNKNOWN
(2 rows)

 iop-select, as implementation of the new stack-selector, logic seems to report the right
[root@spins1 data]# /usr/bin/iop-select status zookeeper-client
zookeeper-client -
[root@spins1 data]# /usr/bin/iop-select status zookeeper-server
zookeeper-server -

 So I guess the question now is, why the components are not advertising the correct version
and they are marked as version = unknown even after installation?

 I saw versions for HDP rpms and installed components are  in the format | ZOOKEEPER      | ZOOKEEPER_SERVER    | | ZOOKEEPER      | ZOOKEEPER_SERVER    | | ZOOKEEPER      | ZOOKEEPER_SERVER    |

 Is this expected in the rpm name/version?  Are we missing some x.x.x.x-yyy required format
in Ambari 2.4 and the parse could be failing?
 I also realized that now the packages to be installed (as defined in service metainfo.xml)
require the stack version (it used to be wildcards * on Ambari-2.2.2)

How are they connected?
Once again thanks for your insights Alejandro  

    On Tuesday, July 26, 2016 4:05 PM, Alejandro Fernandez <>

 Hi Juanjo, in order for the cluster_version to transition to CURRENT as
part of the installation, all of the components in the stack that
advertise a version (through some means like hdp-select) must actually
start up on that version.
Can you provide more details?

SELECT repo_version_id, version FROM repo_version;
SELECT * FROM cluster_version;
SELECT h.host_name, hcs.service_name, hcs.component_name, hcs.version FROM
hostcomponentstate hcs JOIN hosts h ON hcs.host_id = h.host_id ORDER BY
hcs.version, hcs.service_name, hcs.component_name, h.host_name;


On 7/26/16, 2:37 PM, "Juanjo Marron" <>

>Hi all,
>Last days I was working on creating a new stack definition based on
>branch-2.4 code and targeting to test new stack featurization and
>extensibility features.
>The main goal is to create a new stack by reusing current common-services
>code and changing installation path (different to /usr/hdp/) and stack
>version number (diff to 2.5)
>Once the stack was created, I was installing same service rpms we used in
>previous distribution based on Ambari-2.2 and  im hitting  issues with
>cluster state set to current on DB (state is still INIT). Actually the
>components installed maintain their version as unknown in DB and hosts
>state is also out of sync what seems due to same version issue.
>Additionally current_version is never included in hostLevel params in
>command-xx.json file and structured-out-XX.json doesnt show the
>stack_version either
>Is there any important change in how rpms for Ambari-2.4 need to be build
>in terms of versioning compared with Ambari-2.2.2 and previous versions?
>Are there any spec files to build rpms available as reference in some
>other repo or as part of the Ambari code?
> It seems they are strongly coupled to what Ambari framework and stacks
>are expecting. Some documentation where I can read about it.
>I can provide more details about the current test if required, but I
>think at this point I am missing some piece in the management of the
>stack version between rpms and Ambari framework
>I would really appreciate any help or comment
>Thanks all for your time

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message