New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMBARI-22945. Enhance host components API to support multiple host component instances. #467
AMBARI-22945. Enhance host components API to support multiple host component instances. #467
Conversation
Refer to this link for build results (access rights to CI server needed): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've run unit tests that were changed in this PR, and there are about 100 additional errors compared to the base feature branch.
before:
Tests run: 455, Failures: 11, Errors: 48, Skipped: 8
after:
Tests run: 455, Failures: 14, Errors: 148, Skipped: 8
Hi @adoroszlai, I have as of now worked on getting the tests compiled, so that we get the changes in and unblock others. |
@swapanshridhar It took only about 2 hours to fix unit tests broken by #234 in #473, including the time for the initial run of all unit tests. I think creating follow-up tasks, re-running the tests later, waiting for more Jenkins builds, etc. is more overhead than getting them right the first time. Living with broken tests makes it harder for others to check if they are breaking anything, since it's not as simple as "passing" vs. "failing", rather n vs. n+m failing tests. You have to check the logs to notice the difference, which apparently most people skip. Also, a test may be broken by one change, but if it is not fixed, then another change could be also breaking it without the author noticing. |
…mponent instances.
724d37f
to
a9d7fe4
Compare
Following was changed in it :
|
Refer to this link for build results (access rights to CI server needed): |
|
Okay. As of now, I have worked on changes suggested by @jayush which I have mentioned already as part of updates to the Pull request. I'll work on getting the UT's fixed. |
Refer to this link for build results (access rights to CI server needed): |
@swapanshridhar Thanks for working on the UTs, too. Can you please check your latest commit (f126f65)? It added a patch file instead of the actual changes. |
Refer to this link for build results (access rights to CI server needed): |
Closing this Pull request. Tracking changes at : #477 |
What changes were proposed in this pull request?
BACKGROUND:
Given that in Ambari, we refer components of a services in 2 ways:
1. One from the Service component APIs :
http://:8080/api/v1/clusters//services//components/
2. From the host component APIs (which tell us the host on which the current component is resides)
http://:8080/api/v1/clusters//hosts//host_components/
Note that, we of now, we are referring both 1and 2 using the component names
But in the multi-component world for Ambari, we will come up with a situation like this, as shown below:
Core -> HDFS -> HDFS_CLIENT
edw -> HDFS -> HDFS_CLIENT
There is no good way to distinguish a given host component in A and B, if we continue to refer them with the component name end point (No. 2 API call).
However, No. 1 call is still fine as we will not allow 2 names for the same component within a given service, thus making it unique and allowing us to continue using the component names endpoint.
WORK DONE
In order to support multi-instance for components of a given service, we need to enhance the Host Components API so that they can distinguish one component instance of a service from another component instance of a service with the same Name.
The way to achieve this is to move Host Components API to be ID (number) based end point, compared to earlier being a name based endpoint. This will allow us to distinguish Core -> HDFS -> HDFS_CLIENT from edw -> HDFS -> HDFS_CLIENT, as an example.
Thus, following changes are required:
New field : component_type (eg: HDFS_CLIENT, HIVE_SERVER, ZOOKEEPER_SERVER etc)
Existing field : component_name will now hold the actual name given for the component at the time of install. For example:
A way to identify the HOST component uniquely via API calls, by way of referring them by ID instead of name.
MODIFIED API CALLs:
CHANGE : New field component_type
POST http://{{AmbariServer}}:8080/api/v1/clusters//servicegroups/core/services/HDFS/components
Body :
Response:
Body
{"HostRoles":{"cluster_name": "c1","component_name":"HDFS_CLIENT2","component_type":"HDFS_CLIENT"}}
GET SERVICE COMPONENT:
CHANGE: host_components sub-resource will be referenced with end point as ID one.
GET http://{{AmbariServer}}:8080/api/v1/clusters//servicegroups/core/services/HDFS/components/HDFS_CLIENT2
Response:
GET HOST COMPONENT:
CHANGE: Called with ID based end point
GET http://{{AmbariServer}}:8080/api/v1/clusters//hosts//host_components/51
Response:
UPDATE SERVICE COMPONENTS
UPDATE HOST COMPONENTS
DELETE SERVICE COMPONENT:
DELETE HOST COMPONENT:
How was this patch tested?
Tested on live cluster, Details given above.