Expose the SPS health endpoint(s)

[LucaCinquini]

Description: make the SPS/Airflow endpoint /health available so it can be included in the Unity monitoring dashboard. See detailed description in this ticket: unity-sds/unity-project-management#101. The latest agreement is to enter the URL as an SSM parameter, for each SPS installation.
Possibly, expose both the Airflow and the WPS-T endpoints as 2 different SSM parameters, for each venue.

U-CS requires this to implement the health checks.

Acceptance Criteria:
o Demonstrate that the URL is available from SSM after each installation, and that the URL resolves correctly (i.e. returns HTTP status code 200).

[LucaCinquini]

From Mike:

Create an SSM parameter following UCS provided naming convention /unity/healthCheck/<MARKETPLACE_ITEM>/<COMPONENT_NAME>/url and store airflow/health endpoint as the URL

For SPS SSM parameter name will be /unity/healthCheck/sps/airflow

the SSM param should be automatically created after a deployment of the service.

[LucaCinquini]

New direction from Galen - note this is different than the previous specification:

SPS Team: please note that healthCheck SSM params in a venue should be of this form:
/unity/healthCheck/${PROJECT}/${VENUE}/<MARKETPLACE_ITEM>/<COMPONENT_NAME>

[drewm-swe]

What should the project be in the case of unity-venue-dev, unity-venue-test and unity-venue-ops?

Would venue be dev, test, or ops? I'm not sure how this naming convention is able to handle multiple SPS deployments per account...

It seems like we would need a naming convention like this to handle the case of multiple deployments per account:
/unity/healthCheck/${PROJECT}/${VENUE}/<MARKETPLACE_ITEM>/<DEPLOYMENT_NAME>/<COMPONENT_NAME>

[LucaCinquini]

In these cases, I think we need a convention for the project. It could be what you say, or I'd rather say project="unity" (same across the 3 venues). And wouldn't DEPLOYMENT_NAME be the field to handle multiple deployments per account?

[drewm-swe]

I agree with you that unity could be used as the project for the following accounts: unity-venue-dev, unity-venue-test and unity-venue-ops.

Deployment name could be the field to handle multiple deployments per account, however, that field is not contained in U-CS' current naming convention:
/unity/healthCheck/${PROJECT}/${VENUE}/<MARKETPLACE_ITEM>/<COMPONENT_NAME>

[drewm-swe]

My understanding is that they want to have venue represent the deployment name. So for example, venue would be ORT1 and it would be deployed into an INT account. I think using the venue name in that way is fine but I think we should include dev/int/ops in the resource names as well in order to give operators an indication of what type of account their venue resides in.

[LucaCinquini]

Ah yes I was looking at your proposal instead: /unity/healthCheck/${PROJECT}/${VENUE}/<MARKETPLACE_ITEM>/<DEPLOYMENT_NAME>/<COMPONENT_NAME>

Let's ask Galen at the meeting this AM.

[LucaCinquini]

and are setup when the MC is deployed.

Example of possible SSM keys:

/unity/healthCheck/unity/drew-dev-1/sps/airflow_ui

/unity/healthCheck/unity/luca-dev-2/sps/airflow_ui

[LucaCinquini]

TODO: SPS needs to consolidate counter, deployment_name and venue into the new "venue" name as completely free form.

[GodwinShen]

@LucaCinquini ping for status update

[LucaCinquini]

@jpl-btlunsfo has not started on this yet. A pre-requisite is #59 (deployment of SPS via MC) which is still undergoing several issues.

[GodwinShen]

Blocked by #59

[mike-gangl]

Just to recap: This ticket is \ not blocked by #59 . health check endpoints are purely SSM prams. it doesn't need to be in the marketplace for health checks to work. In fact, we've descoped marketpalce deployment and so that wont be there, but we'll still need the health check information created when SPS does a deployment.