incubator-ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Beerbower (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-2699) API to expose Ambari Server resource
Date Mon, 22 Jul 2013 15:48:49 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tom Beerbower updated AMBARI-2699:
----------------------------------

    Description: 
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.



  was:
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://ec2-23-22-113-137.compute-1.amazonaws.com:8080/api/v1/services/AMBARI
",
  "ServiceInfo" : {
    "service_name" : "AMBARI",
    "state" : "STARTED",
    "desired_configs" : { 
      "global" : {
        "tag" : "version3"
      }
    }
  },
  "components" : [
    {
      "href" : "http://ec2-23-22-113-137.compute-1.amazonaws.com:8080/api/v1/services/AMBARI/AMBARI_SERVER",
      "ServiceComponentInfo" : {
        "component_name" : "AMBARI_SERVER",
        "service_name" : "AMBARI"
      }
    },
    {
      "href" : "http://ec2-23-22-113-137.compute-1.amazonaws.com: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.



    
> 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