You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Robert Levas (JIRA)" <ji...@apache.org> on 2015/05/29 21:13:17 UTC

[jira] [Updated] (AMBARI-11396) Kerberos: UI shows Kerberize Cluster step as failed with a retry button, but the backend keeps moving forward to Kerberize the cluster

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

Robert Levas updated AMBARI-11396:
----------------------------------
    Attachment: AMBARI-11396_01.patch

Attaching a patch to help speed up the time it takes to generate the stages needed to enable Kerberos. 

This entails moving the bulk of the processing to a new (preparation) stage.  Because of this, {{org/apache/ambari/server/controller/KerberosHelper.java}} was changed to an interface and the implementation was moved to {{org/apache/ambari/server/controller/KerberosHelperImpl.java}}.  To provide the logic for the preparation stages, a set of new classes were created {{org/apache/ambari/server/serveraction/kerberos/Prepare*KerberosServerAction.java}} which rely on the KerberosHelper and {{org/apache/ambari/server/serveraction/kerberos/AbstractPrepareKerberosServerAction.java}} for shared code.

Patch File [^AMBARI-11396_01.patch]

> Kerberos: UI shows Kerberize Cluster step as failed with a retry button, but the backend keeps moving forward to Kerberize the cluster
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-11396
>                 URL: https://issues.apache.org/jira/browse/AMBARI-11396
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.0.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>              Labels: kerberos
>             Fix For: 2.1.0
>
>         Attachments: AMBARI-11396_01.patch
>
>
> Precondition: On the cluster where this was observed, there were previous attempts to kerberize the cluster.
> STR:
> Go through the Enable Kerberos Wizard.
> The only non-default option taken was to not manage krb5.conf (presented on the second page of the wizard).
> Chrome developer tool shows that there was a POST on /api/v1/clusters/woah/artifacts/kerberos_descriptor failing with 409.  
> {code}
> {
> "status" : 409,
> "message" : "Attempted to create an artifact which already exists,
> artifact_name='kerberos_descriptor',
> foreign_keys='{Artifacts/cluster_name=woah}'"
> }
> {code}
> It doesn't seem like this is the cause of the issue (though we need to investigate).
> The UI keeps showing a spinner for several minutes, then shows a failure.
> This is because a call to PUT on the cluster resource to set security_type takes more than 3 minutes, and the browser aborts the request.
> However, the backend kept moving forward to Kerberize the cluster (ambari-server.log was being tailed to check on progress).
> After verifying that all principals and keytabs were generated/distributed, the wizard was closed (the last step of the wizard is to start all services and run service checks, but this was skipped because the previous step failed.)
> The cluster was in fact successfully Kerberized.
> *Note:* The condition is likely to have occurred due to a timeout related to the number of hosts and services in the cluster.  The preparation phase of enabling Kerberos is performed within the handler of the relavant API call. Most of this work should be moved out to a stage which is handled asynchronously.



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