Removing Blades from Offline gatway

[RasmusH]

Hi Checkmates! 

We have an issue with our management(MDS) when an Identity Awareness -blade is not disabled/removed before the gate is taken offline.
ex:
One of our gateways was taken offline. And all gates in our environment has IA-blade enabled for the sake of being able to handle network tags from AWS and Azure. (Data Center Objects).

But when a gate with IA is not responsive you get a time out in the round robin update of data center objects/tags

Checkpoint management server error:
"
03/05/21 11:16:27,565 ERROR datacenter.util.CommandExec [gateway-updater_<GATEWAYNAME>]: Command '[/opt/CPshrd-R80.40/bin/cprid_util, -server, <GW-IP>, putfile, -local_file, /opt/CPmds-R80.40/customers/cma2/CPsuite-R80.40/fw1/tmp/GATEWAYNAME_vsecUpdate.sh, -remote_file, /tmp/GATEWAYNAME_vsecUpdate.sh]' failed with code 3. Stdout=''. Stderr=''.
"
"
03/05/21 12:03:04,605 ERROR ida.api.IDACpridRequestSenderClient [gateway-updater_GATEWAYNAME]: Failure 1/5 to send script file to gateway ip: <GW-IP>
"

During the period the server tries to update this gateway, all other updates is at a standstill. So with our AWS environment that is constantly changing IP's the deploys etc get slowed down with about 1 minute every 60 sec. (def update interval.) 


When like in this case a gate is offline and have IA activated. You can't simply uncheck the IA blade and install, since you can't install a offline GW. We have had other cases when gates is decommissioned and we missed to disable IA before it was shut down. Then we solved it; removing the cluster completely from the management. 

Is there a solution to disable the blade on a Offline Gateway in the management config or a better workaround for this issue? 

[Tobias_Moritz]

Have you tried disabling IA blade in the offline gateways and do an "Install database" afterwards?

I guess this would inform management about disabled IA blade for this gateway.

I've never tested this, so this is just a wild guess.

[RasmusH]

Thanks Tobias, I will try this out, I think we might have tested it. But since our aws production is suffering during the delay period we did not have much time to test.  I will recreate the issue in a lab env en try it. 

[RasmusH]

Unfortunately this did not help. Even disabling IA blade and installing database, did not help our issue. 
Still get: 

779 ERROR ida.api.IDACpridRequestSenderClient [gateway-updater_GATEWAYNAME]: Failure 3/3 to send script file to gateway ip: GATEWAY-IP

780 ERROR ida.requests.IDARequestsSender [gateway-updater_GATEWAYNAME]: Error while attempt to connect to server: GATEWAY-IP

Making slow update/deploys on new instances in aws. Since the TAG's don't update in the management the instances don't get the correct access. Like a auto-scaled service and we get interruptions in or services. 

We are now looking (since R81) on changing the timeouts and retires in the cloud_proxy config.