juju-info should include the remote charm and open ports

The way to do that is to have a relation with the respective service (nagios <=> monitored service, in that case).

Nice bug number, by the way. :-)

we can add more information to the juju-info service, but gustavo correctly points out that instead nagios should have a requires http or mysql, etc. and then that relation will be used in preference to a juju-info relation type based on the one primary service provides.

Excerpts from Kapil Thangavelu's message of Mon May 14 22:09:04 UTC 2012:
> we can add more information to the juju-info service, but gustavo
> correctly points out that instead nagios should have a requires http or
> mysql, etc. and then that relation will be used in preference to a juju-
> info relation type based on the one primary service provides.
>

The more that we get "for free" the better.

We will of course teach nagios and all the other monitoring solutions how
to speak to most of the interfaces. But I think we can give users *more*
when we don't know how to speak an interface.

If we know the open ports, we can add generic "connect to that port"
monitors. If we know the protocol, we can even have them test more
basic functionality.

With knowledge of the charm, we can group the service's
hostgroup into even bigger host groups. So the 3
services that use the 'mysql' charm can all be grouped into
'mysql-services'. We can also group by OS series, so we can have
precise->mysql-servers->[session_dbs,transactional_dbs,slave_dbs]

If we get the relationships too, we can relate services in nagios as
well, so service dependencies can be detected (when mysql goes down,
you want an alert about mysql, not that the login services that depend
on it are down).

I can do all of this by adding loads of code to charms, but I think
this makes a lot more sense in the juju-info relationship, since it is
already known data about the other side of the relationship.

> If we know the open ports, we can add generic "connect to that port"
> monitors. If we know the protocol, we can even have them test more
> basic functionality.

This is exactly the kind of information that the relation is supposed to provide.

The open ports of the charm is private information about the *unit*, not part of any specific relation.

Excerpts from Gustavo Niemeyer's message of Tue May 15 20:12:26 UTC 2012:
> > If we know the open ports, we can add generic "connect to that port"
> > monitors. If we know the protocol, we can even have them test more
> > basic functionality.
>
> This is exactly the kind of information that the relation is supposed to
> provide.
>
> The open ports of the charm is private information about the *unit*, not
> part of any specific relation.
>
>

As somebody who is actually writing and reviewing a lot of charms,
it isn't realistic to expect every charm to implement every interface
that we come up with immediately. But it will be useful to users to
have rudimentary monitoring for all services that they deploy. Knowing
the charm + ports will enable exactly that, and more emergent behavior
that will prove quite useful over time. Not having them means a massive
effort to implement anything that might be able to use them.

Here's another use case. I want to implement egress filtering for an
SSH host for users to ssh into and then have access *only* to the things
related to that service, and only on the ports that the admins of said
services intend to have open. This is a pretty common scenario.. I want
the devs to be able to ssh in and do commits, maybe poke at the deployment
machinery, but not actually have direct access to the databases, memcached
servers, etc. etc.

You're basically saying to do that, I have to add a provides: relationship
with exactly the same information as open-port would provide, on every
single service.

Why say no to something harmless and *useful*? Its pretty rude to just
close a bug as Invalid because you don't think it makes sense.

As someone else who also writes and reviews charms regularly, I can appreciate the value of having the open ports of a service available for generic use. With such information, we drastically reduce the amount of work needed to get a monitoring system ( for example ) up and running.

Such information can also be beneficial in the charm testing arena as we would have more information to test against.

My two cents ( +1 on Clint's request )

-Juan ( negronjl )

> As somebody who is actually writing and reviewing a lot of charms,
> it isn't realistic to expect every charm to implement every interface
> that we come up with immediately.

That's a straw man argument. There's nothing indicating someone should do this in this thread.

> Knowing the charm + ports will enable exactly that, and more emergent behavior

No, it won't. You can't monitor a port without knowing what protocol is being spoken on it. A charm can't assume it knows what another author is doing with the ports on her own charms. open-port is not what this whole thread makes it look like.

(...)
> You're basically saying to do that, I have to add a provides: relationship
> with exactly the same information as open-port would provide, on every
> single service.

Another straw man. I'm not saying that. I'm saying that to communicate between charms, you need to use a relation, because that's the proper way to do that in juju. It's as simple as that. open-port means something else.

> Why say no to something harmless and *useful*? Its pretty rude to just
> close a bug as Invalid because you don't think it makes sense.

I've closed the bug as invalid because what you've been pointing out is invalid, Clint. Do not assume more than that, please.