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] [Created] (AMBARI-1399) SPI and API Tasks related to cleanup and simplifying API development.
Date Tue, 12 Feb 2013 18:55:13 GMT
Tom Beerbower created AMBARI-1399:
-------------------------------------

             Summary: SPI and API Tasks related to cleanup and simplifying API development.
                 Key: AMBARI-1399
                 URL: https://issues.apache.org/jira/browse/AMBARI-1399
             Project: Ambari
          Issue Type: Task
            Reporter: Tom Beerbower
            Assignee: Tom Beerbower
             Fix For: 1.3.0


SPI and API Tasks related to cleanup and simplifying API development. Broad bucket but will
add more items and supporting documents.

# *Refactor to remove AmbariManagementController*
We should be able to pull all of the AmbariManagementControllerImpl code into the specific
resource provider implementations. This would allow us to get rid of the AmbariManagementController
interface which has grown to become a maintenance issue.  It will also allow us to factor
out a lot of code that is in place to deal with the fact that the controller doesn't handle
predicates directly. Adding futrue functionaly becomes easier since resource provider deals
directly with predicates.
# *Refactor resource providers to remove special cases for configuration*
The configuration resource provider changed the SPI model somewhat in that it isn't able to
provide a set of supported properties. Instead it provides a set of arbitrary properties under
a known category (i.e. "properties").  Specialized code was added to allow for this in the
configuration resource provider as well as the service and component resource providers. 
The SPI has since been cleaned up to the point where it should be possible to remove this
specialized code and handle it with a generic mechanism.
# *Remove SPI dependencies on other code (i.e. org.apache.ambari.server.api.util.TreeNode
in org.apache.ambari.server.controller.spi.Resource)*
Third parties writing resource providers shouldn't have to depend on anything outside of the
SPI package.
# *Clean up Predicate code around BasePredicate to remove need for casting*
Some specialized predicate behavior is exposed through the BasePredicate object instead of
the Predicate interface which causes a requirement to cast from a Predicate to a BasePredicate
in some cases.  The Predicate hierarchy should be cleaned up to remove this requirement if
possible or make it cleaner if not.
# *Clean up PredicateBuilder to make it more usable (i.e remove need for casting to internal
types while maintaining compile time checks for correctness)*
The predicate builder feature makes use of specialized internal builder classes to enforce
correct builder syntax at compile time. In some cases, this makes the builder more difficult
to use since these internal classes are not really intended to be exposed to the end user.
# *Add additional predicate objects to support more complex queries through the API (e.g.
containsKey(), containsValue())*
We should review what types of queries that users are likely to make and add predicate objects
to support them.  An example would be the CategoryIsEmptyPredicate that was added to support
an API partial result request of ?ServiceInfo/desired_configs.isEmpty()
# *Add SPI support for specifying order of resources and metrics in results*
Currently a get through a resource provider returns a set of resources, each containing a
map of properties/metrics.  There is no way currently to specify order.
# *Normalize all category/property/metric names available through the API*
There is no standard for the property names available through the API.  For the most part,
the public name of a metric is the same as the internal name from the back end (Ganglia, JMX,
Ambari DB).  This includes a mix of upper case, lower case, camel case, underscore, dashes,
etc...  We should define a standard for the public facing names that we expose through the
API.  We need to come up with a mechanism that exposes the new public names but also makes
the existing names available for some time (unless we simply cut over to the new names for
the next API version).

--
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