SSVM goes into alert state if secstorage.allowed.internal.sites is set to an IP (not CIDR)

[Pearl1594]

ISSUE TYPE

• Bug Report

COMPONENT NAME

SSVM

CLOUDSTACK VERSION

4.19.2 and above

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

Historically, it was possible to set IP addresses to secstorage.allowed.internal.sites global setting. In 4.19.2 with the inclusion of the following check: https://github.com/apache/cloudstack/pull/9567/files#diff-86103c46b8773747d21e718c0a245134a6c8bb7880d4b6ee959c47f8396cbad7R630-R632, we only accept CIDRs - which seems to be a regression

As reported by: https://lists.apache.org/list?users@cloudstack.apache.org:lte=1M:SSVM%20Agent%20Alert%20State

STEPS TO REPRODUCE

Set  `secstorage.allowed.internal.sites`  to an IP and recreate SSVM.

EXPECTED RESULTS

SSVM should come up

ACTUAL RESULTS

SSVM goes into alert state

SecondaryStorageListener says there is an error in the connect process for 69 due to Invalid CIDR: 192.168.50.6 com.cloud.utils.exception.CloudRuntimeException: Invalid CIDR: 192.168.50.6
    at com.cloud.utils.net.NetUtils.getCleanIp4Cidr(NetUtils.java:634)
    at org.apache.cloudstack.secondarystorage.SecondaryStorageManagerImpl.getAllowedInternalSiteCidrs(SecondaryStorageManagerImpl.java:404)
    at org.apache.cloudstack.secondarystorage.SecondaryStorageManagerImpl.generateFirewallConfiguration(SecondaryStorageManagerImpl.java:437)
    at com.cloud.storage.secondary.SecondaryStorageListener.processConnect(SecondaryStorageListener.java:87)
    at com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:553)
    at com.cloud.agent.manager.AgentManagerImpl.sendReadyAndGetAttache(AgentManagerImpl.java:1116)
    at com.cloud.agent.manager.AgentManagerImpl.handleConnectedAgent(AgentManagerImpl.java:1135)
    at com.cloud.agent.manager.AgentManagerImpl$HandleAgentConnectTask.runInContext(AgentManagerImpl.java:1227)
    at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
    at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
    at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
    at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
    at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:840)

[DaanHoogland]

@Pearl1594 , I see the isValidIp4Cidr(cidr) check in other places as well, so why would it be wrong in this place? Should we amend the methos to allow a single address as a valid /32 cidr?

[Pearl1594]

Yes, I think it should identify IPs as /32 to behave like it used to.

[weizhouapache]

fixed by #10174