On 23 February 2017 at 01:46, James Beedy <jamesbe...@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.bis...@canonical.com> -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju