allow open-port to expose several ports

[Kapil Thangavelu]

http://askubuntu.com/questions/337075/ubuntu-juju-firewall-expose-question

[Jean Deruelle (jean-deruelle)]

+1. See duplicate just opened https://bugs.launchpad.net/juju-core/+bug/1271319

This affecting us to charm a Java Media Server which needs RTP ports to be open in a 1K range of ports and opening ports through EC2 console is a no go for us especially when you need to scale up multiple instances to cope up with increased load in media traffic. Is it possible to use ec2-api-tools to workaround it as it is critical for us.

[William Reade (fwereade)]

We're not likely to be able to fix this easily until we've done more work on the networking model (which *is* scheduled in the next few months). Using ec2-api-tools directly would indeed let you modify the security groups out of band, and is surely more amenable to automation than using the console, but still doesn't feel all that helpful.

The workaround right now would be to use "firewall-mode: global" in your environment config, and to manually (console or ec2-api-tools) open the desired range on the single shared security group when you bootstrap (or first deploy this service, or whatever); but this demands (1) a fresh environment, because firewall-mode is immutable and (2) a sanguine attitude to having those ports opened on *all* your instances, not just instances of this service. Does this help at all?

[Jean Deruelle (jean-deruelle)]

Why do you think ec2-api-tools would not be that helpful ? Is there a way to get the security group of a given instance through juju ?

What I had in mind was to use the following :

# Find out security group
SECURITY_GROUP=`ec2-describe-group $SECURITY_GROUP_JUJU_NAME | grep 'GROUP' | awk '{print $2}'`
# Unblock ports 64535-65535 to be used by MMS
ec2-authorize $SECURITY_GROUP --protocol udp --port-range 64535-65535 --cidr 0.0.0.0/0

[Jean Deruelle (jean-deruelle)]

Also using "firewall-mode: global" and "having those ports opened on *all* your instance" is not possible.

[clearwater (projectclearwater)]

We're hitting this problem as well - one of our packages includes a TURN server where we need to open a range of 16K UDP ports. The output from juju status isn't pretty ...

Other orchestration environments support this fine.

[Dustin Kirkland  (kirkland)]

Also see 3-year-old original report against the Python Juju project: https://bugs.launchpad.net/juju/+bug/845616

Can we please get this bug assigned to someone and in-progress?

Thanks!
Dustin

[Dimiter Naydenov (dimitern)]

Port ranges can be opened, closed, or listed by charms, using:
 - open-port <from>[-<to>][/<protocol>] (e.g. open-port 80-90/tcp, open-port 443/udp, or open-port 10-20 - tcp is the default, udp also allowed).
 - close-port <from>[-<to>][/<protocol>] (e.g. close-port 80-90, close-port 443/udp, or close-port 10-20/tcp)
 - opened-ports (new hook command; returns a sorted list of ports or ranges opened by the current unit; supports --format yaml, json, and smart as default). Example output (always sorted first by protocol, then by port numbers), using the default "smart" format:
10-20/tcp
80-90/tcp
443/udp

All open and close operations on ports or ranges take into account what's already opened on the unit's assigned machine and conflicts are reported as errors from open-port and close-port. Also, all pending ports operations are committed when the current hook is finalized and checks for conflicts are done again, making it possible for the hook to fail, but the chance is remote, as we already pre-validated the ports. All this makes open-port and close-port sandboxed, like all the other hook commands.

Some additional work will be done in the near future (once the networking model evolves further) to link opened ports to relations and infer the network from there, but for now the feature as requested can be considered finished and usable.