Hi Adamos,
*"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?"*
- Presently the logic in AmbariManagementControllerImpl.updateServices /
updateComponents / updateSCH will ignore the S / SC / SCH, if the oldState
= newState, before proceeding to stage creation. We only update what is
changed. The addClientSchForReinstall is more of a hack because we do not
have Configure action. This would change in the future with 1.5.0 release.
So back to the problem of re-installing clients what happens with current
trunk is that, no SCH is found for which a state change happened, thereby
no client component got re-installed.
Your analysis of why the SCH does not get re-installed is accurate, you
should probably open a JIRA about this. If the addClientSchForReinstall looks
at changeServices and changeComps, the desired behavior can be achieved.
If you want to upload a patch for a fix that would be great as well.
Workarounds:
Note: Since you are using the API to achieve this, at least that is what I
think you are doing, you can issue an install on the SCH level,
Example:
curl -u admin:admin -i -X PUT -d '{"RequestInfo":{"context":"Reconfigure
Client"},"Body":{"HostRoles":{"state":"INSTALLED"}}}'
http://localhost:8080/api/v1/clusters/c1/hosts/*<hostname>*
/host_components/HDFS_CLIENT
Other option is a dummy SLAVE /MASTER in your service definition, the START
/ STOP would be NOOPs, note: this can be on any host doesn't have to be the
client host, the addClientSchForReinstall would still work.
Best Regards,
Sid
On Mon, Oct 7, 2013 at 9:36 AM, Sumit Mohanty <[email protected]>wrote:
> +Sid
>
> *Sid*, can you look at the issue Adamos identified and see if you can
> suggest a solution.
>
> -Sumit
> From: ADAMOS LOIZOU <[email protected]>
> Reply-To: <[email protected]>
> Date: Monday, October 7, 2013 12:45 AM
> To: "<[email protected]>" <[email protected]
> >
> Subject: Re: Reconfiguring services with client only components
>
> 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
> changedServicesparameter
> *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]>
> 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]>
> Reply-To: <[email protected]>
> Date: Friday, October 4, 2013 3:49 AM
> To: "[email protected]" <[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
>
--
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.
