GSLB sync removes non-GSLB entities associated with GSLB config causing config loss

In netscaler configuration if you have a GSLB service added using the "existing server" option on Slave node but the same is not present on Master node. Then if GSLB sync is issued from Master to Slave node, it should remove the additional "GSLB service" present on Slave node. This is because?? the “sh gslb runningconfig” of Master node will not have the "add server" command as this is a non-gslb entity/config.

But the issue is when initiating a force sync it not only removes the "GSLB service" present on Slave node, but also removes the "add server" command associated with the backend server IP. This can cause an issue and will unbind the "add server" commands bound anywhere else in the configuration.

For example:
===

From the config analysis:
===
??
From the config, Servername srv-A?? is associated with 2 different services as well as bound to a LB Service Group in Site MASTER.
??
add server srv-A 10.10.10.10
add service lb_svc_1 srv-A TCP 444
bind serviceGroup sg_lb srv-A 444
bind serviceGroup sg_lb srv-A 445
add service lb_svc_1 srv-A TCP 445
??
The same server name is used on the other Site SLAVE?? as well and associated with 2 different services, ?? bound to a LB Service Group as well as used in GSLB Service.
??
add server srv-A 10.10.10.10
add service lb_svc_1 srv-A TCP 444
bind serviceGroup sg_lb srv-A 444
bind serviceGroup sg_lb srv-A 445
add service lb_svc_1 srv-A TCP 445
add gslb service gslb-serv srv-A ANY 80 -publicIP 10.20.20.20 -publicPort 80?? -siteName Slave

When a force gslb sync was performed from Site Master to Site Slave
??
the “sh gslb runningconfig” of Site Master doesn’t have the ?? “add server srv-A 10.10.10.10", as it is not associated with any gslb entity.
However, “sh gslb runningconfig” of Site Slave?? would have “add server srv-A 10.10.10.10", as it was associated with a gslb service.
??
Hence, ?? when a force gslb sync was performed from Site Master to ?? Site Slave, ?? it removes the ?? server - srv-A from SLAVE site , as it is not present in Master.
??
Hence, the related service/serviceGroup config got removed as well from Slave site and resulted in a config loss.
??

If server entity is assocaited with both gslb and non-gslb entities on one site (site1) and only with non-gslb entity on another site (site2) and if sync is performed from site2 then it removes the server on site1. But when the server is removed on site1, it removes the entities associated with it as well (in this case lb service and gslb service) which results in config loss.

Our engineering team has made the changes in this behavior so that the non-gslb entities associated with GSLB entities are not completely removed from the box.

As part of the GSLB force sync, Netscaler deletes the GSLB Config from the slave node and then configures the slave to make it similar to the master node.

The complete fix will be available in below branches:

11.0-64+ ?? and 10.5-61+

Changes made in the code are as below:
===
A hidden flag (-removeGslbSvcOnly) is added to rm server -name- command which indicates to remove only the gslb services associated with the server. After removing the gslb services if the server has no other bindings (service/svc_group) then we go ahead and remove the server else the server will be retained.??

If server entity is assocaited with both gslb and non-gslb entities on one site (site1) and only with non-gslb entity on another site (site2) and if sync is performed from site2 then it removes the server on site1. But when the server is removed on site1, it removes the entities associated with it as well (in this case lb service and gslb service) which results in config loss.