none
How do I troubleshoot endpoint problem with REST service on HPC 2012 server?

    Question

  • I went thru the steps required to enable REST services on the HPC server. According to the PS script everything went according to plan (including creating of self-signed cert on port 443). However, the following symptoms are occurring:
    • no client seems able to connect to any REST endpoints (ie no response from server)
    • accessing https://{localhost/headnode/FQDN}:443/windowshpc shows a Service page with the description "Endpoint not found."
    • any other link similar to localhost:443 results in Page Not Found or a similar msg

    It doesn't seem like these services are being hosted on IIS. Need help/ideas re: how to troubleshoot this problem. Ultimately, I just want the basic REST services working so I can begin to code against them.

    -Ricardo

    Friday, June 07, 2013 8:31 PM

Answers

  • You do not mention if your REST instance is configured to use NTLM or Basic but try the following uri from a browser:

    https://your-hn-name-or-ip-here/WindowsHPC/Clusters?api-version=2011-11-01

    The identity of the REST call must be registered with the HPC headnode as either User or Administrator.   For example:  if you are logged on as an AD account that is registered with the HPC HN AND the REST API is configured to use NTLM then IE will "just work" and return the list of clusternames (only one right now).

    I suggest the above URI to start with because the fragment you mention above is malformed.  The only place for an fqdn is in the spot "your-hn-name-or-ip-here" in my example.  All HPC REST API calls follow the pattern: https://your-hn-name-or-ip-here/WindowsHPC/your-cluster-name-here/...  where "your-cluster-name-here" is NOT an FQDN but one of the responses from the URI I mention above.  The only current exception is the metascheduler call I show above... which is used to discover the clusternames permitted to the given identity.

    As you deduced, the REST API is not currently hosted in IIS.

    If you are poking at the REST API from Linux then the API would need to be using Basic Auth and the appropriate headers would need to be crafted to specify the well-known-identity to use for the call.

    d

    Thursday, June 13, 2013 8:34 PM

All replies

  • You do not mention if your REST instance is configured to use NTLM or Basic but try the following uri from a browser:

    https://your-hn-name-or-ip-here/WindowsHPC/Clusters?api-version=2011-11-01

    The identity of the REST call must be registered with the HPC headnode as either User or Administrator.   For example:  if you are logged on as an AD account that is registered with the HPC HN AND the REST API is configured to use NTLM then IE will "just work" and return the list of clusternames (only one right now).

    I suggest the above URI to start with because the fragment you mention above is malformed.  The only place for an fqdn is in the spot "your-hn-name-or-ip-here" in my example.  All HPC REST API calls follow the pattern: https://your-hn-name-or-ip-here/WindowsHPC/your-cluster-name-here/...  where "your-cluster-name-here" is NOT an FQDN but one of the responses from the URI I mention above.  The only current exception is the metascheduler call I show above... which is used to discover the clusternames permitted to the given identity.

    As you deduced, the REST API is not currently hosted in IIS.

    If you are poking at the REST API from Linux then the API would need to be using Basic Auth and the appropriate headers would need to be crafted to specify the well-known-identity to use for the call.

    d

    Thursday, June 13, 2013 8:34 PM
  • Although all the details in your message are helpful, it is the API Version info that ultimately solved our problem. We realized that we needed to add that info in the C# code we were using to test the services, and now you've shown that we can also add it to the URL.

    By adding the API Version, everything is now working as expected.

    I would suggest calling this detail out a little more prominently in the documentation.

    Thursday, June 13, 2013 8:48 PM
  • Indeed, api-version can be specified on the url or in the api-version header.

    I included it in the C# samples back in V3SP3 when it was introduced... and it is covered in the newly updated MSDN content like Get Clusters

    Versioning in the REST API is not a trivial topic.  New features and/or behaviors are not available unless the api-version payload is present and is greater-than-or-equal to the version in which the feature/behavior was introduced. 

    Supplying an api-version payload is the best practice for current and future RESTful calls... but it can currently be omitted if the caller limits calls to features shipped in V3SP2.  However, this calling convention is only supported for backwards compatibility.  The current best practice is to always provide an api-version payload.

    Error response body content is also controlled by api-version payload.  A much richer response body is provided if the api-version payload is present and correctly specifies a version greater-than-or-equal-to V3SP3.  The C# Samples show this as well.

    d

    Thursday, June 13, 2013 10:58 PM