opened-ports doesn't include ports opened by other charms

[Nick Veitch]

the `opened-ports` hook tool seems like a useful way to avoid conflicts for co-hosted charms (as two charms can't open the same port on the same machine).

However, `opened-ports` only returns ports opened by the current running charm. e.g.

charm# opened-ports <- returns nothing
charm# open-port 8080-8100
    error: cannot open 8080-8100/tcp (unit "kafka/0"): conflicts with existing 8080/tcp (unit "mysql/0")

Whilst this behaviour may be justifiable to some degree, it is potentially confusing and seems like an incomplete solution.

[Aaron Bentley (abentley)]

It seems a little strange that opening a port that is already open isn't a no-op. I guess it's because expose works by service name?

[Alvaro Uria (aluria)]

I'm reopening this issue as we're hitting a bug (see bug 1750490) that could potentially be solved if a charm could check if a port is already opened.

The nrpe charm enables logic on the principal application, so hyperconverged openstack scenarios would be hit:
* ceph-osd: check if processes are running
* ceph-mon: check "ceph health"
* nova-compute: check if processes are running
* nrpe-charm: generic checks (disk, cpu, load, ...)

the nrpe-external-master relation enables the above logic on non-nrpe charms, but the nrpe-charm needs to "open-port".

In BootStack scenarios, we use "maas" as juju provider, which I think would not need "open-port" (as the "openstack" provider would, to add secgroup rules). Is there a way for the charms to know which provider is in use by Juju and act differently (ie. if maas -> skip_open_port).

[John A Meinel (jameinel)]

open-port hints that the charm is about to use that port to do something.
If you call open-port and that port is already opened by another charm,
then another application is using that port, so you can't open it for your
use.

Is the issue that you're running multiple instances of the same
application, for which only one will ultimately be running, and 2 charms
are trying to configure it?

On Wed, Mar 28, 2018 at 1:06 PM, Alvaro Uría <email address hidden>
wrote:

> I'm reopening this issue as we're hitting a bug (see bug 1750490) that
> could potentially be solved if a charm could check if a port is already
> opened.
>
> The nrpe charm enables logic on the principal application, so
> hyperconverged openstack scenarios would be hit:
> * ceph-osd: check if processes are running
> * ceph-mon: check "ceph health"
> * nova-compute: check if processes are running
> * nrpe-charm: generic checks (disk, cpu, load, ...)
>
> the nrpe-external-master relation enables the above logic on non-nrpe
> charms, but the nrpe-charm needs to "open-port".
>
> In BootStack scenarios, we use "maas" as juju provider, which I think
> would not need "open-port" (as the "openstack" provider would, to add
> secgroup rules). Is there a way for the charms to know which provider is
> in use by Juju and act differently (ie. if maas -> skip_open_port).
>
> ** Also affects: juju
> Importance: Undecided
> Status: New
>
> ** Tags added: canonical-bootstack
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1427770
>
> Title:
> opened-ports doesn't include ports opened by other charms
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1427770/+subscriptions
>

[Alvaro Uria (aluria)]

@jam yes, that's exactly the problem:
juju deploy cs:nova-compute --to 1
juju deploy cs:ceph-osd --to 1
juju deploy cs:nrpe
juju add-relation nova-compute nrpe
juju add-relation ceph-osd nrpe

https://git.launchpad.net/nrpe-charm/tree/hooks/services.py#n44
https://git.launchpad.net/nrpe-charm/tree/hooks/services.py#n44

The charm should have a better logic to not fail if the port is already opened, but it would be more accurate if it could:
1) do_nothing if juju provider is maas
2) skip the action if a peer unit has already opened it
3) fail if someone else is using the port

[Alvaro Uria (aluria)]

Second link should be:
https://git.launchpad.net/nrpe-charm/tree/hooks/charmhelpers/core/services/base.py#n325

[Peter Sabaini (peter-sabaini)]

@jam -- I also wonder what the semantics of open-port here are. The charm is registering a port for use - but has it to be exclusive, eg. with proto=icmp?

[John A Meinel (jameinel)]

The ultimate effect is that we would cause a firewall rule to be written
that would include the port that you have specified.
I do believe the reason to force conflict is to assist charms in
understanding that there is something else that is already using that port.
As far as I understand, a charm that chooses to catch the error from
open-port is certainly allowed to do so. I don't believe we immediately
fail the hook, it is just that most charms do so. (The charm *could* be
written to treat open-port failing as a non-fatal error.)

We have talked internally about extending open-port to be more of a
"suggested port[s]" such that if the desired one isn't available, you give
a way for Juju to inform the charm to fall back to another suitable port.
I do believe that today a charm could ask to open a port, see the error,
then try a different port if it wanted to, and could then host the
application at that new port.

On Wed, Mar 28, 2018 at 11:56 PM, Peter Sabaini <<email address hidden>
> wrote:

> @jam -- I also wonder what the semantics of open-port here are. The
> charm is registering a port for use - but has it to be exclusive, eg.
> with proto=icmp?
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1427770
>
> Title:
> opened-ports doesn't include ports opened by other charms
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1427770/+subscriptions
>