floci-ui connection to gcp problem

[Omsupe15]

Description

The Floci UI web console (launched and managed via the floci AWS environment sidecar) fails to establish a connection to a locally running floci-gcp instance, despite strictly following the multi-cloud setup documentation.

The floci-gcp emulator itself is completely healthy and responds perfectly to local (gcloud) requests on the host machine. However, the UI adapters do not bridge the connection to the GCP runtime environment.

Expected Behavior

When configured according to the multi-cloud documentation, the Floci UI sidecar container should be able to resolve, connect to, and manage the floci-gcp emulator context alongside the AWS emulator context.

Actual Behavior

The UI fails to connect to the GCP emulator. Attempts to route the endpoint to local ports result in connection failures or unresolvable routing blocks inside the browser network logs.

Steps to Reproduce

1. Start the floci-gcp emulator locally (verifying that it responds successfully to direct API calls/CLI commands).
2. Start the standard floci (AWS) environment with the Floci UI sidecar enabled.
3. Access the Floci UI via the browser.
4. Attempt to switch to the gcp panel which returns service unavailable.

Environment Details

• Operating System: Windows 11
• How Floci AWS is run: Docker Compose
• How Floci GCP is run: Docker Compose
• Floci UI Docker Image Version: latest

Additional Context

The underlying issue seems to stem from how the automated AWS sidecar UI container isolates its internal container networking, causing cross-container or container-to-host translation adapters to fail when pointing to the unified GCP emulator port (4588).

[identity-wael]

The endpoint needs to be reachable from the UI's API process, not just from Windows or the browser. In the current UI GCP client, it is read from FLOCI_GCP_ENDPOINT and otherwise defaults to http://localhost:4588. Inside a UI container, that default points back to the UI container itself.

The UI's multi-cloud Compose example sets this on the API service:

environment:
  FLOCI_GCP_ENDPOINT: http://floci-gcp:4588
  FLOCI_GCP_PROJECT: floci-local

It also puts the API and floci-gcp on the same Docker network. With two separate Compose projects, floci-gcp normally won't resolve from the AWS/UI project's network unless you explicitly share a network. On Docker Desktop for Windows, the alternative is http://host.docker.internal:4588 if the GCP container publishes that port to the host and it is reachable that way.

Two checks would distinguish the failure:

1. Inspect the environment and networks of the actual generated UI sidecar. Setting FLOCI_GCP_ENDPOINT only on the AWS emulator container doesn't establish that the sidecar received it.
2. From that UI container, request http://<chosen-host>:4588/_floci-gcp/health; then check the console's /api/clouds/gcp/status response.

The AWS sidecar documentation describes injecting its own AWS endpoint; the explicit multi-cloud Compose configuration is a useful way to remove that auto-sidecar layer while diagnosing this. If the GCP health request succeeds from the UI container but the cloud status still fails, share the image digest and sanitized status response—the issue is then beyond basic host/container reachability.

[hectorvent]

When Floci-UI is launched from Floci (AWS) or any future emulator, it won’t be able to connect to other emulators for now.

We can iterate on cross-emulator connectivity later since it’s not urgent. In the meantime, if you need to connect across multiple clouds, please run the UI in standalone mode.