As a developer, I want a developer staging system with the latest dev versions of PDS services deployed

NASA-PDS / devops

Parent repo for PDS DevOps activities

Apache License 2.0

0 stars 0 forks source link

As a developer, I want a developer staging system with the latest dev versions of PDS services deployed #2

Closed jordanpadams closed 1 year ago

jordanpadams commented 3 years ago

Motivation

...so that I can easily test services and clients against those services

Additional Details

Acceptance Criteria

Given When I perform Then I expect

Engineering Details

We want some generic tool / service identified and a process documented for continuous deployment of PDS EN services that are in development. This capability to be possible for services that may be deployed either (or both):

[ ] on prem
[ ] in AWS

things to thing about:

will this need to be separate from public Github Actions in order to access our internal servers / AWS services?
- how often do we want to do this? on push to master? nightly? weekly?
- we will need to handle some sort of post-deployment capability (e.g. deploy registry + ingest some data)?

tloubrieu-jpl commented 2 years ago

The services we want are (TBC):

[x] registry
[ ] DOI service and UI

jordanpadams commented 2 years ago

DOI Service on hold per #128

jordanpadams commented 2 years ago

Basic integration setup complete. awaiting test username/password from @tloubrieu-jpl

jordanpadams commented 2 years ago

Basic integration setup complete. awaiting test username/password from @tloubrieu-jpl

tloubrieu-jpl commented 2 years ago

The pds-jenkins machine was done for a few weeks, but @nutjob4life will be able to deploy it as soon as it is back.

A reverse proxy also needs to be set up by the SAs, @nutjob4life will create a ticket for that.

nutjob4life commented 2 years ago

Waiting on https://itsd-jira.jpl.nasa.gov/servicedesk/customer/portal/16/DSIO-2067

tloubrieu-jpl commented 2 years ago

I don't believe it is related by similar behavior was corrected on registry-api https://github.com/NASA-PDS/registry-api/issues/141

nutjob4life commented 2 years ago

Note that neither the DOI service nor the Registry seem to work when under a subpage. That is, these reverse-proxies only partially work:

Registry API: http://pds-dev.jpl.nasa.gov/expo/ → pds-expo:8443/expo
DOI: https://pds-dev.jpl.nasa.gov/doi/PDS_APIs/pds_doi_api/0.2/ui/ →pds-expo:3177/

The issue is that either our software or the Swagger layer used by both Registry API and DOI are not compatible with subpage existence. These apps prefer to answer to / and not /expo or /doi.

Towards finding a better alternative, I've asked the sysadmins to create 2 new CNAMEs so that neither Registry API nor DOI have to be on a subpage, i.e., they will answer at /:

Registry: https://pds-dev-registry.jpl.nasa.gov/
DOI: https://pds-dev-doi.jpl.nasa.gov/

See the ticket for more details.

I hope this solves the recurring issue with both services.

nutjob4life commented 2 years ago

The new endpoints without sub-pages are functional!

Give them a try at:

tloubrieu-jpl commented 1 year ago

This works. In a next ticket TBD we want to have the same url scheme as in production.