DR Environment Decommissioning - Need Runtime Marked as Stopped (Build to Remain)

0
Hi everyone and thanks in advance.Currently I have a Mendix application hosted on AWS. I have previously created a Disaster Recovery (DR) environment for this application, which was only used in case of a discrepancy with the primary environment.I are now decommissioning this DR environment. As part of that process, I have already deleted the underlying AWS resources - VPC, Kubernetes cluster, and nodes.As a result, the Mendix Gateway Agent for this environment/namespace is now disconnected, and the Mendix Portal cannot reach the cluster. When I try to click "Stop Application" from the environment's General page, I get the following error:"I encountered an issue when attempting to send the request to the cluster."This is expected, since the cluster no longer exists, but it leaves the environment stuck showing a stale "1/1 replicas running" status with a persistent "Agent is disconnected" banner.What I would like to achieve: - Keep the environment record and its currently loaded build/package information in the Portal (for reference/rebuild purposes). - Have the Runtime status reflected as Stopped/Disabled, since the app is no longer running anywhere.Could you advise on the best way to handle this on your end, given that the agent cannot be reconnected (the cluster has been permanently deleted)? I do not want to fully delete the environment from the Portal at this time - I'd like to retain it in a stopped/inactive state for record-keeping.If anyone has any ideas to this problem please let me know. Thank you again .
asked
2 answers
1

Hi,

What you're seeing is expected behaviour for a connected Mendix on Kubernetes environment. The Portal has no independent view of the cluster. The runtime status ("1/1 replicas running") is just the last state the Mendix Gateway Agent reported before it lost connection. Once the cluster is gone, nothing can send a new status update, so the Portal keeps showing the stale value. As far as I know, there's no Portal action to manually mark an environment as stopped. Every runtime action (Stop, Start, Transport) goes through the agent and the Operator to the MendixApp CR in the cluster.

Given that, I would advise the following:

Raise a Mendix Support ticket (recommended)

This is the cleanest route if you want to keep the environment record. Explain that the cluster has been permanently deleted and ask them to set the environment's runtime state to stopped on the Portal side. Include the app ID, environment name/internal name and namespace.
Good luck,
Fjordi

answered
0

Hi Tushar,


In this situation, I would not try to use Stop Application anymore. The important detail is that the Kubernetes cluster and the Mendix Agent have already been removed.


The Stop Application action is not just a Portal-side status change. Mendix sends the desired state to the cluster, where the application is scaled down to zero replicas. Since the Agent/cluster no longer exists, the Portal has nothing to send that request to, which explains the “Agent is disconnected” message and why the old 1/1 replicas running status remains visible.


I also would not manually modify the replica count or other MendixApp/Runtime resources in the Portal or database to make the environment appear stopped. Those resources are managed by the Mendix Operator and should be changed through the supported deployment mechanisms.


If you want to retain the environment and its loaded build/package information for reference, I would keep the environment as-is rather than deleting it. The disconnected state is effectively telling you that the Portal no longer has a connected cluster behind that environment.


The current Mendix documentation does provide a way to delete an environment when the Agent is disconnected, and the recent Deploy API also supports force-deleting an orphaned environment. However, that would remove the environment from the Portal, so I would not use that option if retaining the environment record is a requirement.

In your case, I would raise this with Mendix Support and explain that:

  • The Kubernetes cluster has been permanently decommissioned.
  • The Mendix Agent can no longer reconnect.
  • The environment needs to be retained in the Portal for historical/build reference.
  • You want the stale runtime/replica status to be cleared or the environment marked inactive without deleting the environment record.


I would include the Environment ID, App ID, namespace, last deployment package/version, and screenshot of the disconnected Agent status in the support request.

So the situation is essentially:

Kubernetes cluster
      ↓
Deleted
      ↓
Mendix Agent unavailable
      ↓
Portal cannot send Stop Application request
      ↓
Old runtime/replica status remains stale

There isn't a supported Portal action to convert that disconnected environment into a normal Stopped state after the underlying cluster has already been permanently deleted. The supported cleanup option is to delete the orphaned environment, but that conflicts with your requirement to retain it for record-keeping.


Hope this helps.

answered