Hi Sid, Thank you very much for the analysis and reply.
In the end, we chose to reintroduce the parameter and code fragment in AmbariManagementControllerImpl so as to return to the previous behaviour without impacting the way we treat the Ambari REST API. I have created a JIRA ticket for it and provided the aforementioned fix with a patch. https://issues.apache.org/jira/browse/AMBARI-3489 Thanks again. Adamos On 7 Oct 2013, at 20:20, Siddharth Wagle <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[email protected]>> Reply-To: <[email protected]<mailto:[email protected]>> Date: Monday, October 7, 2013 12:45 AM To: "<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[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 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 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
