Add ans-web-ui for app-user and app-provider. …

[peterkvokacka-da]

… [ci]
also changing base ports. New calculated ports will be outside of OS's dynamic port range in order to prevent port bindings problem like this:

Failed to bind to address /0.0.0.0:35002

Pull Request Checklist

Cluster Testing

• If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

• Include any change that might be observable by our partners or affect their deployment in the release notes.
• Specify fixed issues with Fixes #n, and mention issues worked on using #n
• Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

• Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

[moritzkiefer-da]

I'm confused, in slack we discussed to keep it, why are you removing it now.

[peterkvokacka-da]

We discussed it further with etx team. Work was already done (in both splice and QS) and we decided to proceed with removal. Are you ok with that? I makes Splice LocalNet cleaner.

[moritzkiefer-da]

Hm if Curtis wants to keep devnet support in QS I'd lean towards also keeping it here.

In the end if app devs do want this, we have plenty of app devs that just use localnet but don't care about all of QS.

[hrischuk-da]

@peterkvokacka-da let's not make this change.

Here is a very simple diagnostic use case that I've used 10s of times because DevNet can have challenges.

1. Try to run my app on DevNet to incorporate all the delays that occur in a Gsync. The app fails mysteriously.
2. Switch back to LocalNet and run my app. It passes.
3. Go get a coffee and wait for DevNet to become more stable.

Even if DevNet is super stable, I forsee that the different behaviro between LocalNet and DevNet still require dev testing on both.

So, let's wait for feedback that provides some signal to remove the ability to run on DevNet.

[filmackay-da]

@hrischuk-da this is not a question about access to devnet - it's a matter of whether that support is built into Splice Localnet, or QS. The scenario you outline is not in question with QS, only with those using raw Splice Localnet.

[peterkvokacka-da]

ok I removed the removal of devnet support from the PR.

[moritzkiefer-da]

This looks problematic to me. Ports up to 1024 require root on Linux. I don't think we should use this for localnet.

[peterkvokacka-da]

those are just "base" ports never used directly. always combined with env prefix e.g.

2${PARTICIPANT_LEDGER_API_PORT} for app user
3${PARTICIPANT_LEDGER_API_PORT} for app provider
4${PARTICIPANT_LEDGER_API_PORT} for sv

documented here https://github.com/peterkvokacka-da/splice/blob/peterkvokacka-da/remove-devnet-support-from-splice-localnet/cluster/compose/localnet/README.md#exposed-ports

[moritzkiefer-da]

Suggested change

	- **PARTICIPANT_ADMIN_API_PORT**: 902
	- **PARTICIPANT_JSON_API_PORT**: 975
	- **VALIDATOR_ADMIN_API_PORT**: 903
	- **CANTON_HTTP_HEALTHCHECK_PORT**: 900
	- **CANTON_GRPC_HEALTHCHECK_PORT**: 961
	- **PARTICIPANT_LEDGER_API_PORT**: X901
	- **PARTICIPANT_ADMIN_API_PORT**: X902
	- **PARTICIPANT_JSON_API_PORT**: X975
	- **VALIDATOR_ADMIN_API_PORT**: X903
	- **CANTON_HTTP_HEALTHCHECK_PORT**: X900
	- **CANTON_GRPC_HEALTHCHECK_PORT**: X961

[moritzkiefer-da]

Suggested change

	These patterns apply to the following ports:
	These patterns apply to the following ports where X is 2, 3 or 4 as described above:

[moritzkiefer-da]

Let's rename this to port suffix or something like that. Otherwise it's super confusing that this is not the actual port that ends up being used.

[peterkvokacka-da]

done

[moritzkiefer-da]

thanks!