[
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_02.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, AMBARI-11396_02.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)
