{section}
{column}
h1. Introduction
When a topology is declared as [dynamic|Topology Configuration], several operating tasks can be done to modify the topology:
* move a running container from a domain to another domain,
* detach a running container from its current domain.
When a topology is declared as [static|Topology Configuration], the topology can't be modified, but can be deleted from the registry cluster for administrative reasons.
{column}
{column:width=350px}
{panel:title=Operating Topologies}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}
h1. Dynamic Topologies
h2. Moving a container
Both a container of an autonomous topology and a container member of a more complex topology can be attached to another existing topology (aka domain).
{gliffy:name=Moving a container standalone|align=center|border=false|version=7}
The attachment is realized through the JMX API (or [Petals CLI|petalsclisnapshot:Petals ESB CLI 3.2.0-SNAPSHOT]) of the container to move using the method '{{attachContainerTo}}' of the MBean '{{Topology}}' with the following parameters:
* a container member of the target domain,
* the topology pass-phrase of this remote container.
During the attachment process, the container attached is reconfigured to use the registry of the target domain. After the attachment, the endpoints of the container moved are available in the target topology, and not in the initial topology anymore.
h2. Detaching a container
Any container member of a dynamic domain can be hot-detached at any moment. After detachment, the container is running in a dedicated standalone topology, i.e., in a dedicated domain.
{gliffy:name=Detaching a container|align=center|border=false|version=6}
The detachment is realized through the JMX API (or [Petals CLI|petalsclisnapshot:Petals ESB CLI 3.2.0-SNAPSHOT]) of the container to detach using the method '{{detachContainer}}' of the MBean '{{Topology}}'.
After the detachment, the endpoints of the container are not available in the initial topology anymore and are moved to the new one.
h2. Empty Topologies
When all container of a dynamic domain are detached from it, then the topology is empty.
In that case, the empty topology is automatically removed from the registry cluster.
h1. Static Topologies
By definition, static topologies can't be modified once registered in a registry cluster the first time.
But for administrative reasons, it can be desired to clean a topology by deleting it from the registry cluster.
This can be done using the command '{{delete-topology}}' of [Petals Registry CLI|petalsregclisnapshot:Petals Registry CLI 1.3.0-SNAPSHOT]).
{column}
h1. Introduction
When a topology is declared as [dynamic|Topology Configuration], several operating tasks can be done to modify the topology:
* move a running container from a domain to another domain,
* detach a running container from its current domain.
When a topology is declared as [static|Topology Configuration], the topology can't be modified, but can be deleted from the registry cluster for administrative reasons.
{column}
{column:width=350px}
{panel:title=Operating Topologies}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}
h1. Dynamic Topologies
h2. Moving a container
Both a container of an autonomous topology and a container member of a more complex topology can be attached to another existing topology (aka domain).
{gliffy:name=Moving a container standalone|align=center|border=false|version=7}
The attachment is realized through the JMX API (or [Petals CLI|petalsclisnapshot:Petals ESB CLI 3.2.0-SNAPSHOT]) of the container to move using the method '{{attachContainerTo}}' of the MBean '{{Topology}}' with the following parameters:
* a container member of the target domain,
* the topology pass-phrase of this remote container.
During the attachment process, the container attached is reconfigured to use the registry of the target domain. After the attachment, the endpoints of the container moved are available in the target topology, and not in the initial topology anymore.
h2. Detaching a container
Any container member of a dynamic domain can be hot-detached at any moment. After detachment, the container is running in a dedicated standalone topology, i.e., in a dedicated domain.
{gliffy:name=Detaching a container|align=center|border=false|version=6}
The detachment is realized through the JMX API (or [Petals CLI|petalsclisnapshot:Petals ESB CLI 3.2.0-SNAPSHOT]) of the container to detach using the method '{{detachContainer}}' of the MBean '{{Topology}}'.
After the detachment, the endpoints of the container are not available in the initial topology anymore and are moved to the new one.
h2. Empty Topologies
When all container of a dynamic domain are detached from it, then the topology is empty.
In that case, the empty topology is automatically removed from the registry cluster.
h1. Static Topologies
By definition, static topologies can't be modified once registered in a registry cluster the first time.
But for administrative reasons, it can be desired to clean a topology by deleting it from the registry cluster.
This can be done using the command '{{delete-topology}}' of [Petals Registry CLI|petalsregclisnapshot:Petals Registry CLI 1.3.0-SNAPSHOT]).