PostgreSQL Use Case/Issues

Stuart Bishop stuart.bishop at canonical.com
Thu Feb 23 08:46:44 UTC 2017


On 23 February 2017 at 01:46, James Beedy <jamesbeedy at gmail.com> wrote:

>> I think I can fix this, but I'll need to make a corresponding
>> adjustment in the PostgreSQL charm and the fix will only take effect
>> with updated services.
>>
> +1 for a fix. Thanks.

>> Its related to the above issue. Your charm connects and gets the
>> db.master.available state set. But you want to specify the database
>> name, so a handler runs calling set_database(). At this point the
>> .master and .standbys properties start correctly returning None, but
>> set_database() neglected to remove the *.available states so handlers
>> got kicked in that shouldn't have.
>>
> Ok, so a fix coming for this too in that case? This one is borking on my
> devs who are deploying my bundles, in turn causing me grief, but also
> borking on me too, making me question my own sanity :(

Yes. I'll push a fix out shortly.


>> need more control, you can use the set_roles() method on the interface
>> to have PostgreSQL grant some roles to your user, and then grant
>> permissions explicitly to those roles. But this doesn't really help
>> much from a security POV, so I've been toying with the idea of just
>> having clients all connect as the same user for the common case where
>> people don't want granular permissions (even if it does make security
>> minded people wince).
>
> Will the "common use case" be the only use case?

I think I need to support both approaches. I don't want applications
to outgrow Juju once they become complex enough to warrant per table
permissions. How this happens, I don't know yet; I haven't yet come up
with a design I like enough to pursue further. I don't think you'll
see any changes here until LTS+1, because it will likely need
backwards incompatible changes.

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



More information about the Juju mailing list