[jira] [Assigned] (AMBARI-13398) Blueprints: Implement REST resource for storing Kerberos descriptors

["Sebastian Toader (JIRA)" <ji...@apache.org>]

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

Sebastian Toader reassigned AMBARI-13398:
-----------------------------------------

    Assignee: Sebastian Toader

> Blueprints: Implement REST resource for storing Kerberos descriptors
> --------------------------------------------------------------------
>
>                 Key: AMBARI-13398
>                 URL: https://issues.apache.org/jira/browse/AMBARI-13398
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: trunk
>            Reporter: Laszlo Puskas
>            Assignee: Sebastian Toader
>
> h2. Support for saving a Kerberos descriptor to the REST API in Ambari
> In order to support referring to a Kerberos descriptor by name in the Cluster Creation Template (POST-ing a Kerberos descriptor to a REST resource, then referring to it during Blueprint deployment), we’ll need a new REST resource defined in the Ambari REST API.  
> We’ll need the ability to POST a kerberos.json descriptor document to:
> http://ambari-host:ambari-port/api/v1/kerberos_descriptors/kerberos_descriptor_name
> Where {code}kerberos_descriptors{code} is the collection resource for all Kerberos descriptors to be saved to the back end.  This can be any number of descriptors that are POST-ed, and the fact that a descriptor is posted here is not necessarily an indicator that it is used in a cluster deployment.  This is similar to how the {code}blueprints{code} resource works, in that the documents are saved in the Ambari DB to be referenced later by deployments (Blueprint deployments in our case). 
> The {code}kerberos_descriptor_name{code} can be any arbitrary name given to the customer’s customized kerberos descriptor.  This can be a partial document, listing only the overrides necessary, as the default Kerberos descriptors will be merged by the Kerberos framework when the Kerberization is setup.  
> For most Blueprint deployments that require Kerberos, the Blueprint or Cluster creation template will reference this “kerberos_descriptor_name” when indicating the kerberos descriptor used to configure Kerberos for this cluster. 
> There needs to be support for:
> 1. POST-ing a Kerberos descriptor to this REST endpoint
> 2. Obtaining the list of Kerberos descriptors by making a GET call on the following URL:
> http://ambari-host:ambari-port/api/v1/kerberos_descriptors
> 3. Obtaining a named Kerberos descriptor by making a GET call on the following URL:
> http://ambari-host:ambari-port/api/v1/kerberos_descriptors/kerberos_descriptor_name
> This portion of the Blueprints Kerberos support is not necessarily Blueprint-specific, and should be implemented without any direct references to Blueprint code or constructs.  
> h2. Ambari Database Upgrade issues 
> The addition of this new resource type will require the creation of one more more database tables in order to store the Kerberos descriptors in the Ambari back-end.  
> This current task will encompass any Database table changes needed to make these additions, and will also likely require some ambari-server Upgrade handling. This will involve using the existing Ambari Upgrade utilities to support moving from older Ambari installs to Ambari 2.2. The main work here will be updating existing database tables to support the new structure. For this particular task, this will likely mean that an upgrade will need to add the new tables to the Ambari Database.  
> h2. Existing Example of this type of resource
> The Ambari REST API includes many services and ResourceProvider implementations that could serve as a model for this implementation.  The "blueprints" resource is probably the most straightforward in this case.  
> Example of a Service interface that must be defined for each resource:
> {code}org.apache.ambari.server.api.services.BlueprintService{code}
> Example of a ResourceProvider implementation that must be defined for each resource:
> {code}org.apache.ambari.server.controller.internal.BlueprintResourceProvider{code}
> Example of a resource definition that must be defined for a new resource:
> {code}org.apache.ambari.server.api.resources.BlueprintResourceDefinition{code}
> There may be other classes required for this implementation, but the Blueprint resource pattern is probably the best starting point for this current task.  
> h2. Ambari REST API Documentation
> The following link shows the Ambari REST API Documentation, which will likely be useful during this task:
> https://github.com/apache/ambari/blob/trunk/ambari-server/docs/api/v1/index.md
> h2. Examples of Kerberos Descriptors
> The default Kerberos descriptors are defined in the stacks, and can be found at the service-level and stack-level.  
> In the trunk repo, the stack definitions for the "HDP" stack can be found in:
> {code}ambari/ambari-server/src/main/resources/stacks/HDP{code}
> All of the Kerberos Descriptors in the stacks are named "kerberos.json".  
> From the directory mentioned above in the stack definitions, the following shows the default kerberos descriptors for the "HDP" stacks:
> {code}
> find . -name "kerberos.json"
> ./2.0.6/kerberos.json
> ./2.2/services/YARN/kerberos.json
> ./2.3/services/ACCUMULO/kerberos.json
> ./2.3/services/KAFKA/kerberos.json
> ./2.3/services/TEZ/kerberos.json
> ./2.3/services/YARN/kerberos.json
> ./2.3.GlusterFS/services/ACCUMULO/kerberos.json
> ./2.3.GlusterFS/services/TEZ/kerberos.json
> {code}



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