add-unit relation question

[David Britton]

Stuart --

This may true but for my particular case, I'm only dealing with one
postgresql unit.  What is breaking is the addition of a second *client* to
one postgresql server on the admin relation.  I mean, it's racy, I actually
did test successfully, but most of the time it fails.  Simply retrying the
relation works since by that time the pg_hba.conf file certainly has had a
chance to be updated already.


On Mon, Jun 3, 2013 at 11:15 AM, Stuart Bishop
<stuart.bishop at canonical.com>wrote:

> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130603/e93d8e29/attachment.html>