Known issues and limitations

IBM strives to keep issues in IBM Hybrid Cloud Mesh (Mesh) to a minimum, but occasionally they can't be avoided. Learn about the issues and limitations in this version. IBM is aware of these issues and is working hard to address them as quickly as possible.

Red Hat® Service Interconnect gateway known issues

  • In some circumstances, a gateway might show an Unreachable health status, but the gateway communications still work. The Skupper pods and router function correctly. This problem occurs if the Mesh agent becomes unavailable and therefore can't transmit a heartbeat. When the Mesh agent becomes available again, the gateway shows an Operational status.
  • When you deploy a gateway, several Skupper-related pods start running. However, it might take some extra time for the health status of the gateway in the Mesh console to change to Operational. The amount of extra time depends on the conditions in your networking environment.
  • In some circumstances, if you delete a gateway, any connection access policies that manage the applications on the gateway stop working. For example, this problem occurs when you delete a gateway from a namespace where applications are deployed that are managed by a connection access policy. Even after you re-create the gateway, the services for the application might not be published.

    To work around these issues, delete then re-create the policy.

  • If you create a second deployment of a service that is published by using a connection access policy, you might need to delete and re-create the policy to enable traffic to flow to the second service. This issue occurs when a gateway and a remote connection are present before the new service is deployed.
  • To deploy a Service Interconnect edge gateway, you might need to uninstall then reinstall the Open Horizon agent that you want to use before you deploy the gateway.
  • In some circumstances, when you create a gateway, the pods for the Skupper VAN might not be deployed on the target cluster. This problem can occur if the deployment is manually deleted from the Kubernetes cluster and some Skupper-related pods are deleted too. To work around this issue, complete the following steps:
    1. Delete the gateway that you created.
    2. Unregister the deployment location and the deployment environment.
    3. Uninstall the Open Horizon agent and delete the namespace in the target cluster.
    4. Reinstall the Open Horizon agent in the target cluster.
    5. Register the deployment location and the deployment environment.
    6. Create the gateway again.
  • If you deploy two services in separate namespaces or clusters, to ensure that load balancing operates correctly, create the services before you create the Mesh resources. That is, create the services before the resources connect with one another.
  • If you want to create a policy for a service that is deployed in more than one namespace, you must do one of the following for any additional services:
    • Deploy the service before you create the policy.
    • Deploy the service to a namespace that does not yet have a gateway with a remote connection.
  • Before you delete the instances and service endpoints from an application deployment, you must first disconnect the namespace from the gateway that it is connected to.
  • If you delete a service from a connection access policy by using the CLI, the service is deleted and the policy becomes an orphan policy. If the service is rediscovered when you create another gateway, the service is not automatically covered by the policy.
  • When you create a remote connection between gateways by using the CLI, no validation is done to prevent the creation of a connection between gateways that belong to different network segments.

Metrics known issues

  • When you retrieve metrics information by using the Mesh API or Grafana, the network_segment attributes might be missing from the response object. That is, the following attributes might be missing:
    • app_network_segment
    • app_network_segment_name
    • svc_network_segment
    • svc_network_segment_name
    Even though the attributes are missing from the response object, you can successfully use the network_segment label as a filter in a request in Grafana.
  • When you view application network traffic, you see double the expected number of data points for each metric.
  • In the metrics side panel in the topology view, data might not be displayed in the average latency chart in the application-to-service traffic metrics. This issue might occur even though data is available for Total Flows and Total Bytes. The data in the average latency chart usually refreshes in approximately 30 minutes.

Limitations

  • You can't use the same service names for different applications in the same network segment. For example, if an environment has two applications, app1 and app2, both with the service name myservice, and they are in the same network segment, they are displayed as two deployments of the same application.
  • If you delete a connection access policy, the traffic between the application and the service continues to flow until the application ends the connection. Deleting the policy does not close the connection. In other words, you can’t stop the flow of traffic immediately by deleting the policy.
  • You cannot use internal and external secrets at the same time.