[
https://issues.apache.org/jira/browse/AMBARI-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718627#comment-13718627
]
Tom Beerbower commented on AMBARI-2699:
---------------------------------------
[~satom], currently we only have version 1, but I think that as we add new
versions we would like to support multiple at the same time. We are still
discussing how the user might discover what API versions are available... see
above.
> 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
