Perform Sanity Check on Publication Dates

[thorwolpert]

Each stream to determine a SWAG and compare to dates in Theme.

• define what formed estimate
• effort for tasks

no more than 1/2 dozen or so bullet point
review as team, update dates

• PPR (Primary: Doug)
• NameX (Primary: Thor)
• Business (Primary: Thor)
• Auth (Primary: Sumesh)
• Pay (Primary: Sumesh)
• Common (email gateway, print services, etc) (Primary: TBD - assigned by Patrick) Do we need in the sandbox?

[doug-lovett]

PPR API sandbox setup considerations:

• Standup PPR database with data (effort ? instance already running)
• Standup PPR API instance (effort 1-3?)
• Update gateway configuration (effort 1)
• Update dev site content (effort 0 include with above)

Dependencies:

• Sandbox Auth API/keycloak available
• Sandbox Pay API available

Assumptions:

• PPR OAS current, published

[sumesh-aot]

Keycloak:

• PROD keycloak to be used

Auth API

• Spec needs to be created with the endpoints which would be needed for the partners, API users
• Sandbox Environment - (To Discuss) I was thinking initially to use the PROD auth itself after discussion with Thor long back. But for the business/NR authorizations (affiliations) they would need to affiliate the sandbox businesses/NRs to the account and may pollute PROD data.
  Option 1 - Setup sandbox DB and stand up API. We could use cloud events to replicate the account related data to auth and pay DBs.
  Option 2- Create 2 keycloak clients, 1 for sandbox keys and 1 for prod keys (need changes to current implementation). For sandbox key, add special role to indicate the token is from sandbox. Check this role and return success on authorizations and affiliations calls.

Pay API

• Spec is up-to-date, but a review would be needed to list out the endpoints partners, API users would be using. I believe most of the pay-api calls would be coming from ppr, legal, name request APIs as the integration is baked in. Then focus on them to clean up the schema.
• Sandbox environment : We would need sandbox DB for pay. Setup sandbox pointing to keycloak PROD, and pointing to auth (based on above decision). No jobs needs to be run for external dependencies (CFS, ftp etc.). Some code changes to mark the invoices as PAID upon creation. If we go with 2 client approach with keycloak, we can use the special role to do this.

[sumesh-aot]

Summary of discussion for MVP:

• Cleanup Auth-API Spec.
• Use PROD auth-api for the PPR launch. Users come to account portal, setup account and payment details. Then request API Services access. Task : configure auth-api to point to correct API Gateway environment and do a dry-run.
• When an account requests API access, create these account details on Sandbox pay environment.
• Standup Pay-API in sandbox. Pay-API, Pay-DB, Q services. No need to setup jobs for CFS account creation and invoice creation.
• For Sandbox Pay requests, mark them as PAID on creation.
  ( Dates to be updated after discussing with @jyoti3286 )

After MVP:

• Before business registry (lear) publishes spec. to be used for API users, move auth-api and DB specific to Sandbox as affiliation records would pollute PROD database. Potential data migration here to replicate these accounts in Sandbox.

[jyoti3286]

@Kaineatthelab - when do you want to discuss this? I met with Sumesh and Saravan on the above MVP approach. The overall estimate(ballpark) is around 20-24 points. From our understanding, AUT and PAY API will be internal calls from PPR API - don't think someone would be calling auth and pay directly.

With that assumption, what is the realistic date for PPR Sandbox? Doesn't look like Nov 5 is achievable.

We can definitely test whether an API key generation works on not for Sandbox from backend by Nov 5th.

[Kaineatthelab]

I am ok with this, the main drive of this was to get API work on the board and moving:) It is doing that so your above suggestions of testing on nov 5 is good. Next step... when can we actually open the box:)?

[jyoti3286]

@Kaineatthelab There are four tickets that are created for this piece. We are planning to groom this today and maybe target to complete those in the next 2 sprints. Realistically it can be done in the next SPRINT as well but since this is backend heavy task - I would like to keep it spread in the next 2 sprints if possible so that there is a mixture of tickets for Devs to work on. Long story short - End of Nov or beginning of December.
Also, this is not on our board so we have to look to see what we need to trade-off in this PI for this work