Many roles will need to support running on alternative ports or in multiple instances on multiple ports. Currently, the firewall rules in roles are fixed, read-only values as part of the role definition. We need a supported mechanism for adjusting these rules.
We discussed this on IRC today. Here is a summary of the plan we came up with:
The _SETTINGS version of the firewall rules should be only a set of fixed values that are required to get deployment started. (In most cases, this should mean it's empty).
As part of the role deployment, we expose a wrapper around the firewall client that allows the role to open and close ports as needed to do the deployment.
This wrapper should track all changes so it can be reverted if the deployment fails and saves them for use in decommission later.
Needed wrappers:
openFirewall(ports, services[, persistent])
Open one or more ports or services in the firewall. Records changes for reverting later.
closeFirewall(ports, services[,persistent])
Close one or more ports or services in the firewall. Records changes for reverting later.
getServiceDefinition(service)
Return a list of ports and port-ranges that represents a firewall service. This can be used if a role wants to take most of the defaults of a service but make smaller changes.
Many roles will need to support running on alternative ports or in multiple instances on multiple ports. Currently, the firewall rules in roles are fixed, read-only values as part of the role definition. We need a supported mechanism for adjusting these rules.