Comment 3 for bug 1427770

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
>