[jira] [Created] (AMBARI-1399) SPI and API Tasks related to cleanup and simplifying API development.

["Tom Beerbower (JIRA)" <ji...@apache.org>]

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