add-unit relation question

[Stuart Bishop]

On Mon, Jun 3, 2013 at 10:33 PM, David Britton
<david.britton at canonical.com> wrote:
> Hi All --
>
> I've hit a problem about which I need some advice.  I can think of two ways
> to solve it, but it seems to me a common problem that people must have hit
> before.
>
> My charm (landscape charm, unpublished for now) relates with postgresql over
> the "db-admin" relation.  This relation allows direct access to the database
> as a super user.  The two things the connecting charm needs from postgresql
> are the connection details (host, super-user name, password) and postgresql
> to *allow* the connecting unit access to the database through the
> pg_hba.conf file, adding a db user, setting a password.
>
> This all works fine for the case of the first client unit connecting.  In my
> case -- "landscape".  The second landscape unit I add however hits a
> problem.  It keys off the presence of host (part of the connection details)
> to know if it is ok to connect.  This of course is already set in the
> relation context by the postgresql unit from the previous unit that
> connected  What is missing is the second requirement of allowing the
> connecting landscape unit access to the database through the pg_hba.conf
> file.
>
> I can think of three ways around this situation:
>
> 1) Avoid -- Don't restrict on ip addresses in the pg_hba.conf file.
>
> 2) Workaround -- In landscape, make the connecting process resilient.  It
> would retry for a timeout period before considering it a failure.  This
> would work fine, but would need to be part of the README for any connecting
> service, as it's very non-obvious why you need to do this.
>
> 3) Formally Fix -- Use a setting like "clients-allowed" that postgresql will
> relation-set with the list of ips that are allowed to connect.  Make *that*
> the official way to key on when a connection should be attempted.  Document
> in the README.  The old way would still work, but not for the N+1 case
> (which afaict, it never did).
>
> My question is, what approach should I choose?  Is there something that I am
> missing?  This seems like a pretty typical problem.  As *soon* as a new unit
> is added, the relation variables are in the same state from the previous
> unit, which in some cases, make sense, but only if nothing on the server
> side needs to be done to allow that new client to connect.
>
> How have other people solved this?
>
> Thanks for your help! :)

I'm reasonably certain this is another form of Bug #1184909
(https://bugs.launchpad.net/charms/+source/postgresql/+bug/1184909),
which I would have looked at already except I got side tracked with
test infrastructure so this sort of silly thing doesn't happen again.

What is supposed to be happening is the db-admin-relation-changed hook
should be invoked on each of the server units and granting access to
the client's IP address.

-- 
Stuart Bishop <stuart.bishop at canonical.com>