ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laszlo Puskas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-13398) Blueprints: Implement REST resource for storing Kerberos descriptors
Date Tue, 13 Oct 2015 14:32:05 GMT

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

Laszlo Puskas updated AMBARI-13398:
-----------------------------------
    Attachment:     (was: AMBARI-13398.patch)

> 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: Laszlo Puskas
>         Attachments: AMBARI-13398.patch
>
>
> 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)

Mime
View raw message