incubator-ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Swan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-2699) API to expose Ambari Server resource
Date Tue, 20 Aug 2013 18:08:53 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13745213#comment-13745213
] 

Brian Swan commented on AMBARI-2699:
------------------------------------

The last suggestion for API level resources looks great. I suppose, however, that we should
specify how the API version will be represented. I suggest something simple like v1, v1.1,
v2, etc. in which breaking changes are only introduced in major version revisions.
                
> 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

Mime
View raw message