----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/46199/#review129180 -----------------------------------------------------------
Ship it! Ship It! - Alejandro Fernandez On April 14, 2016, 12:56 p.m., Di Li wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/46199/ > ----------------------------------------------------------- > > (Updated April 14, 2016, 12:56 p.m.) > > > Review request for Ambari and Alejandro Fernandez. > > > Bugs: AMBARI-15866 > https://issues.apache.org/jira/browse/AMBARI-15866 > > > Repository: ambari > > > Description > ------- > > curl -u admin:admin > 'http://myserver.mydomain.com:8080/api/v1/clusters/mycluster?regenerate_keytabs=all' > -X PUT -H 'X-Requested-By: ambari' --data > '{"Clusters":{"security_type":"KERBEROS"}}' > { > "href" : > "http://myserver.mydomain.com:8080/api/v1/clusters/mycluster?regenerate_keytabs=all/requests/15";, > "Requests" : > { "id" : 15, "status" : "Accepted" } > > } > > Notice the "regenerate_keytabs=all" piece in the URL returned by the Ambari > server. If user pulls request status against that URL, he will get the > following err. > > curlit GET > http://myserver.mydomain.com:8080/api/v1/clusters/mycluster?regenerate_keytabs=all/requests/15 > { "status" : 400, "message" : "The properties [regenerate_keytabs] specified > in the request or predicate are not supported for the resource type Cluster." > } > > The correct url should be > http://myserver.mydomain.com:8080/api/v1/clusters/mycluster/requests/15 > > This does not effect Ambari web UI as Ambari UI pulls status of all requests > by /requests url, instead of using individual request URLs. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/api/resources/RequestResourceDefinition.java > cf3f267 > > Diff: https://reviews.apache.org/r/46199/diff/ > > > Testing > ------- > > The issue is general, regardless whether the cluster is kerberized, as it's > about how the href url is parsed. > > kerberized a trunk cluster, patch the cluster with fix. > 1. submit REST API call to renew kerberos keytabs. > Verify the /requests URL returned is valid and can be used to pull request > status. > 2. submit a custom action API (like the host check one). > Verify the existing href behavior is still correct. > 3. Submit a rest api that does not need to return /requests url, like get > stack details REST API > Veriy the existing href behavior is still correct. > > On a non-kerberized trunk cluster, patch the cluster with fix, > Repeat the 3 tests mentioned above. > > > Thanks, > > Di Li > >
