Create a static internal IP on the internal network for virtual nodes.

Summary

The communication between the SSH proxy and the backend host occurs over the internal network. To ensure proper routing, a login node with a stable internal IP in the 10.250.0.0/16 range must be created. This allows the SSH proxy to consistently resolve the login node's hostname across deployments. Without a stable IP, the internal IP must be updated manually after each deployment, leading to operational inefficiencies. The current solution to this issue breaks in prod when you try to define a port on the knightly-network because of dual IP assignment from the same network.

Current Behavior

During deployment, a static internal IP is assigned by specifying the internal port ID through pipeline variables. This approach works as expected in both the development and staging environments, where:

• The internal network is assigned via port ID.
• The external network is assigned via network ID.

Issue in Production

In the production environment, post-deployment, the SSH proxy was unable to route traffic and remained unresponsive. Upon investigation, it was observed that the login node was assigned two internal IPs. This issue arose because:

Both the port ID and network ID referenced the same network. While defining a port is optional, the --network option was always provided, causing dual IP assignment.

Proposed Solution

To prevent dual IP assignment and ensure flexibility in deployment, the --network option provided during the creation of virtual login node server should be made optional in .gitlab-ci.yml. This change will allow a single static internal IP assignment via the port or network definition, ensuring a consistent and predictable deployment process across all environments, including production.