DOCS: Deploy the demo app, connected to DevNet

[ghost]

Background

Create content that corresponds to the section: Deploy the demo app to DevNet

Prior art to see sample of RST format: Read API

More Information Needed

Needs more clarification to understand how this tutorial would be constructed:

• How is this envisaged? Deploy into what infra environment?
• Being a tutorial it needs to be very specific, and tangible - specific commands and expected outcomes.
• What assumptions would be made in the deployment environment? We did something similar for Spider, but this involved a multi-step Quickstart equivalent where the user could step-by-step conduct a setup of a system. Even then it didn't contemplate K8S or similar, as that was wired into client concerns.
• We are trying to envisage how this would be better than inspecting QS/LocalNet via docker-compose setup, and examining it as a container deployment (albeit on a single host).
• Is there something like this for Canton/Canton Network to use as a guide for better understanding the intent?
• How does this relate to QS, other than the fact of "Demo App" (I presume this is QS app).

Task

• Assemble new content in CN-Quickstart repo: /docs/user/qs-deploy-the-demo-app-to-devnet.rst. This is a temporary name that will be aligned with the directory hierarchy of the docs repository, and once we know that we will provide it to you.
• Content:
  • step by step deployment of demo app to DevNet
  • outline tutorial, review with [email protected] and editors
  • write
  • ensure it is covered by automated tests

[meiersi-da]

@filmackay-da : the description seems off, copy and paste error from the SQL part?

[ghost]

@filmackay-da : the description seems off, copy and paste error from the SQL part?

Ack - had not saved amendments :)

[peterkvokacka-da]

I have few questions to understand the intent here: This is only about deploying app that means:

• backend-service
• frontend
• plus maybe few shell scripts for onboarding and to start QS workflow?

This shouldn't be a guide how to deploy validator (AppProvider, AppUser) it should just expect those are already up and running? (judging by these comments ) What about authorization. Will we use shared-secret or oauth2. If oauth2 the steps that would describe how to configure and run IDP are out of scope of this guide, right?

ensure it is covered by automated tests

What do you mean by this? IIUC this guide will cover only how to setup demo app not the whole environment. I presume there will be lot of manual steps in it. So by automated tests you mean that if whole environment is setup and you follow this guide to get demo app working in that environment then if you provide enough input for the tests (using env variables where is my participant, validator, admin name etc.) and run this suite of tests it will test the demo app?

[ghost]

@peterkvokacka-da can you outline the answers,as you understand it, to the above?

[peterkvokacka-da]

• The guide should link existing splice doc how to deploy validator (docker compose or helm charts) and explain to user that we need to configure 2 validators: AppProvider and AppUser.
• To verify all the instructions and code snippets we put into the guide we need to be able to follow the guide ourselves for that reason we should request from help@da google cloud environment for QS. Automated test should be created for that to make sure the guide is not broken with new version canton/splice.
• We should provide step by step instructions how to setup keycloak, pqs, backend-service, frontend
• Finally how they can initialise Licensing Workflow
• Guide will consist of manual steps but we need to be able to verify them by the automated test.

[ghost]

Instead of Keycloak, should we just use Auth0 since the Splice validator instructions refer to that?

[peterkvokacka-da]

We could but we would need to setup tenants in Auth0 specifically for QS. I think we start with Keycloak first.

[peterkvokacka-da]

Simon Meier (DA) [Yesterday at 7:41 PM] On testing of validator deployment. It's done here in splice: https://github.com/hyperledger-labs/splice/blob/main/.github/workflows/build.scala_test_for_compose.yml https://github.com/hyperledger-labs/splice/blob/main/apps/app/src/test/scala/org/l[…]ts/runbook/DockerComposeValidatorPreflightIntegrationTest.scala And it really just deploys the validator and checks that a login in possible.

[peterkvokacka-da]

based on offline discussion I suggest the first steps:

Prerequisites

• Use the Validator Docker Compose Deployment Guide (VDG): https://docs.sync.global/validator_operator/validator_compose.html
• Ensure an app-provider validator is deployed as described in the VDG.

Cloud deployment

• Follow the same approach as the VDG: Docker Compose-based validator deployments use .localhost subdomains for addressing, such as wallet.localhost. .localhost

Authentication

• The default VDG deployment uses self-signed tokens and is insecure. Add the same disclaimer as in VDG: The default deployment uses highly insecure self-signed tokens. Follow the same approach to configure and run PQS and backend service with the shared-secret auth mode.

Testing (similar to what splice does here) on a single hoost:

• Create GitHub Actions workflows (similar to Splice’s Compose workflow) to:
• Download Bundle as per VDG
• Configure and start SV (mimicking real DevNet SV)
• Configure and start app-provider validator as per VDG
• Start PQS, and QS in CI.
• Verify PQS and QS services start successfully and register with the validator.
• Confirm basic end-to-end connectivity between PQS, QS and the app-provider validator.
• Verify that the app-provider can log in to the QS web UI.

Stretch goal

1. Deploy an app-user validator on the same host in a separate Docker network. Verify network and port isolation and update configurations to avoid port conflicts.
2. If (1) succeeds, add CI workflows to:
   • Start the full environment in GitHub Actions.
   • Run a full QS workflow lifecycle Playwright test using shared-secret auth mode (currently missing we have only a test for oauth2 mode) and validate the complete end-to-end flow.

[hrischuk-da]

For clarity, I want to point out that the plan above has two phases:

1. Deploying a Validator with a static IP to DevNet just as a developer would be expected to do. This is used to write the documentation.
2. Validating the documentation is valid by testing this using a simulated DevNet. This will avoid continuously adding new topology state using an automated CI for this test.

[hrischuk-da]

@peterkvokacka-da @filmackay-da I discussed with @meiersi-da in my 1-1 with him and he thinks the plan above is sufficient.