[jira] [Commented] (AMBARI-7201) Common Services

["Newton Alex (JIRA)" <ji...@apache.org>]

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

Newton Alex commented on AMBARI-7201:
-------------------------------------

Nicely written document!

Here are some comments from my side:
1) What would be the common service definitions tested against? Are we looking at Bigtop rpms?

2) Minor fix:
On Page 3, in the directory tree:
| | | | |­ {Base: common­services/1.0.0/SERVICEA}
should be
| | | | |­ {Base: common­services/SERVICEA/1.0.0} 

3) I have some comments on the versioning of the service definitions. We are dealing with two variables here:
i. The versions of the services. e.g. HDFS-2.4, HDFS-2.6
ii. The versions of the service definitions themselves e.g. 1.0.0, 1.0.1 

Consider a scenario where we release the service definitions for HDFS-2.4 and call it HDFS-1.0.0. After some time we release the service definition for HDFS-2.5 and call it HDFS-1.1.0. Now if for some reason we need to patch the service definition for the older HDFS-2.4, what would the version number for such a fix look like? Do we call it 1.0.0.1, 1.0.1 or 1.1.1? 
Basically we will have to establish some guidelines on how we version the service definitions. Versioning the common services will help avoid vendor stack breakages.

I can think of two approaches here:
I> Establish a policy on how to increment the version numbers for the service definitions

We can probably bump up the first digit for newer versions of services.
E.g. 
HDFS-2.4 can be in common-services/HDFS/1.0.0
HDFS-2.5 can be in common-services/HDFS/2.0.0

And bump up the second digit for all patches or revisions to the service definition.
E.g.:
Version 2 of the service definition for HDFS-2.4 would be common­services/HDFS/1.1.0
Version 2 of the service definition for HDFS-2.5 would be common­services/HDFS/2.1.0

Pros:
a. Compact representation
Cons:
a. The version numbers might not linearly increase. What if one vendor chooses to ship HDFS 2.5 but an another doesn't? How do we ensure that the versioning doesn't get messed up?

II> Second option to have explicit versioning like the following:

common-services/HDFS/{service_version}/version/{service_definition_version}
E.g.:
common-services/HDFS/2.4.1/versions/1.0
common-services/HDFS/2.4.1/versions/1.1
common-services/HDFS/2.6/versions/1.0


Pros:
a. Natural/Easy to read service version hierarchy
b. Avoid the necessity for internal version mapping between service and service-definition versions (inside the metainfo.xml files I guess?)
c. If we don't end up supporting HDFS 2.5, then we can simply leave it empty.

I personally lean towards the second approach. Let me know if any of the above approaches will work for us or if there is anything better?

Thanks

> Common Services
> ---------------
>
>                 Key: AMBARI-7201
>                 URL: https://issues.apache.org/jira/browse/AMBARI-7201
>             Project: Ambari
>          Issue Type: Epic
>          Components: stacks
>    Affects Versions: 2.0.0
>            Reporter: Robert Levas
>              Labels: common-services, service, stack
>         Attachments: CommonStackServicesTechnicalDocument.pdf
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> *Problem*
> The current implementation of the Ambari stack does not allow for a common set of services to be defined and reused in vendor-specific stack definitions. Therefore in order for the same service to be made available to different stacks, it’s definition must be copied or inherited from stack to stack.  
> *Solution*
> There needs to be a repository of services that exist outside the scope of any vendor-specific stack, but are accessible to vendor-specific stacks via service inheritance. This set of services should be known as common services and are to be maintained by the community to ensure that changes do not break vendor-specific services that inherit from them. 
> See [^CommonStackServicesTechnicalDocument.pdf] for more information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)