add-unit relation question

[Andreas Hasenack]

On Mon, Jun 3, 2013 at 2:25 PM, David Britton
<david.britton at canonical.com>wrote:

> 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.
>
>
Here are some logs:

This is from landscape/2, the unit that was added:
2013/05/29 19:39:41 DEBUG worker/uniter/jujuc: hook context id
"landscape/2:db-admin-relation-joined:2896530511008022547"; dir
"/var/lib/juju/agents/unit-landscape-2/charm"
2013/05/29 19:39:41 INFO worker/uniter: HOOK Error connecting to database
as db_admin_4_landscape_admin
2013/05/29 19:39:41 ERROR worker/uniter: hook failed: exit status 1

This is the corresponding log from postgresql/0:
2013-05-29 19:39:41 UTC FATAL:  no pg_hba.conf entry for host
"10.154.134.171", user "db_admin_4_landscape_admin", database "postgres",
SSL on
2013-05-29 19:39:41 UTC DETAIL:  Client IP address resolved to
"ip-10-154-134-171.ec2.internal", forward lookup not checked.




>
> 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>
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130603/153b1351/attachment-0001.html>