[
https://issues.apache.org/jira/browse/AMBARI-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718624#comment-13718624
]
Tom Beerbower commented on AMBARI-2699:
---------------------------------------
[~brian_swan], I like the idea of getting the supported API versions through
/api. I'm not sure about having the server resource at that level since it
would be un-versioned, meaning we would never be able to change it. What do
you think about adding an "api" resource as well as a "server" resource?
Getting the "api" resource might look like ...
{code}
GET api/
{
"href" : "http://aaa:8080/api";,
"API" : {
"supported_versions" : "1,2,3"
}
}
{code}
The "server" resource would look something like what is described above and
would be used to get the Ambari server/agent version and configuration.
> API to expose Ambari Server resource
> ------------------------------------
>
> Key: AMBARI-2699
> URL: https://issues.apache.org/jira/browse/AMBARI-2699
> Project: Ambari
> Issue Type: Task
> Reporter: Tom Beerbower
>
> Ambari could simply be added as another service resource with a Server and
> Agent components. Since the Ambari service is not tied to a cluster we would
> need to expose root level services. Something like ...
> {code}
> api/v1/services/AMBARI
> {
> "href" : "http://aaa:8080/api/v1/services/AMBARI
> ",
> "ServiceInfo" : {
> "service_name" : "AMBARI",
> "state" : "STARTED",
> "desired_configs" : {
> "global" : {
> "tag" : "version3"
> }
> }
> },
> "components" : [
> {
> "href" : "http://aaa:8080/api/v1/services/AMBARI/AMBARI_SERVER";,
> "ServiceComponentInfo" : {
> "component_name" : "AMBARI_SERVER",
> "service_name" : "AMBARI"
> }
> },
> {
> "href" : "http://aaa:8080/api/v1/services/AMBARI/AMBARI_AGENT";,
> "ServiceComponentInfo" : {
> "component_name" : "AMBARI_AGENT",
> "service_name" : "AMBARI"
> }
> }
> ]
> }
> {code}
> Some advantages of doing this ...
> 1) Consistent API. The API would not really have to change much... no new
> resource types.
> 2) Ambari server configuration would be exposed through the existing
> configuration resource type. We don't have to explain a new configuration
> resource to the users.
> 3) We can support configuration overrides if that makes sense fot the Ambari
> service.
> 4) We can include Ambari agent info / properties / overrides if that makes
> sense.
> Some questions / issues ...
> 1) Does it make sense from the user perspective to see Ambari as a service?
> 2) We need to expose services at the root level since there is only one
> Ambari service and services are currently only under clusters.
> 3) Do config overrides make sense for the Ambari service?
> 4) Does the version tag part of configurations make sense for the Ambari
> service?
> It probably makes sense to make this a read only resource for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
