Hi Sumit, Thanks for replying.
Here's the info you asked for:
* the config type/tag is persisted
Yes, checking through the API I can see it registered:
{
"href" :
"http://localhost:8080/api/v1/clusters/mycluster/configurations?type=your_custom_service_type&tag=version1381128066056";,
"items" : [
{
"href" :
"http://localhost:8080/api/v1/clusters/mycluster/configurations?type=your_custom_service_type&tag=version1381128066056";,
"tag" : "version1381128066056",
"type" : "your_custom_service_type",
"Config" : {
"cluster_name" : "mycluster"
},
"properties" : { … }
}
]
}
* the tag is selected at cluster level
Yes again, checking through the API:
{
"href" : "http://localhost:8080/api/v1/clusters/mycluster";,
"Clusters" : {
"cluster_id" : 2,
"cluster_name" : "mycluster",
"desired_configs" : {
"core-site" : {
"user" : "_db",
"tag" : "version1379424366421"
},
"your_custom_service_type" : {
"user" : "admin",
"tag" : "version1381128066056"
},
"global" : {
"user" : "_db",
"tag" : "version1379424366421"
},
"hdfs-site" : {
"user" : "_db",
"tag" : "version1379424366421"
}
}
}
...
}
* there exists any entry for that type/tag in table "serviceconfigmapping"
No entry there.
The other possibility is that Starting the service does not create any command
to re-install the client. To confirm this, can you analyze/share the
ambari-server and agent logs when you issue the "Start" command.
I believe that is the case. Please find the relevant logs attached.
The ambari-server registers the STARTED request but neither of the
ambari-agents seem to receive anything (2-node cluster).
I've done some debugging on the Ambari side and so far it seems that the
behaviour change comes from
AmbariManagementControllerImpl.addClientSchForReinstall(…)
The latest version of the method's signature has had the changedServices
parameter removed and only relies on the changedScHosts parameter to proceed
with installing client components.
In this scenario, it is precisely changedServices that registers a change while
changedScHosts remains empty, probably explaining why the client components are
never re-installed.
If that is the case, is there a valid reason for having removed the
changedServices from the method and if so how should we now go about
reconfiguring those client components?
Thanks again for your help.
Kind Regards,
Adamos
On 4 Oct 2013, at 17:00, Sumit Mohanty
<[email protected]<mailto:[email protected]>>
wrote:
Hi Adamos,
We will need some more info to figure out whats going on?
For the latest config update that you did, can you let me know if
* the config type/tag is persisted
* exists in the "clusterconfig" table or,
* through API -
api/v1/clusters/mycluster/configuration?type=your_custom_service_type&tag=your_new_version
* the tag is selected at cluster level
* row exists with "selected" being 1 for that type and tag
* through API - api/v1/clusters/mycluster and check under the property
"desired_config"
* there exists any entry for that type/tag in table "serviceconfigmapping"
* existence of entries here indicates one reason for the issue (let me
know if this is the issue and we can discuss a fix – essentially mimic the
action of "ambari-server upgrade")
The other possibility is that Starting the service does not create any command
to re-install the client. To confirm this, can you analyze/share the
ambari-server and agent logs when you issue the "Start" command.
-Sumit
From: ADAMOS LOIZOU <[email protected]<mailto:[email protected]>>
Reply-To:
<[email protected]<mailto:[email protected]>>
Date: Friday, October 4, 2013 3:49 AM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Reconfiguring services with client only components
Hello,
We use a custom service in our Ambari instance that comprises only of client
components (i.e. no daemons).
We used to control its reconfiguration by:
1. Stopping the service by changing the service state to INSTALLED
2. Changing the cluster configuration with a PUT in e.g.
http://localhost:8080/api/v1/clusters/myclusterwith the following body:
{
"Clusters": {
"desired_configs": {
"type": "your_custom_service_type",
"tag": "your_new_version",
"properties": { }# properties here
}
}
}
3. "Starting" the service by changed the state to STARTED. Even though the
service would always remain in INSTALLED state (as being with client-only
components) it had the effect of applying the changed configuration.
We've recently synced our Ambari version with the latest from trunk and we no
longer see that behaviour (the configuration is not applied).
What would the correct way be of reconfiguring a service with client only
components?
Thank you
Kind Regards
Adamos
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader of
this message is not the intended recipient, you are hereby notified that any
printing, copying, dissemination, distribution, disclosure or forwarding of
this communication is strictly prohibited. If you have received this
communication in error, please contact the sender immediately and delete it
from your system. Thank You.
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
ambari-agent_masternode.log
Description: ambari-agent_masternode.log
ambari-agent_slavenode.log
Description: ambari-agent_slavenode.log
ambari-config-changes.log
Description: ambari-config-changes.log
ambari-server.log
Description: ambari-server.log
