On 27 March 2014 03:49, Andreas Hasenack andr...@canonical.com wrote:
On Tue, Mar 25, 2014 at 12:07 PM, Stuart Bishop
stuart.bis...@canonical.com wrote:
The patch would be like: GRANT DELETE ON TABLE person TO landscape.
That landscape is hardcoded, so that user has to exist and be the
user
On 27/03/14 14:51, Stuart Bishop wrote:
Correct. I think you are just fine with one relation per database and
using the generated credentials, and using the granted roles to
control database permissions.
As a sanity test - would per-relation config be useful in this scenario?
Mark
--
Juju
On 27 March 2014 15:33, Mark Shuttleworth m...@ubuntu.com wrote:
On 27/03/14 14:51, Stuart Bishop wrote:
Correct. I think you are just fine with one relation per database and
using the generated credentials, and using the granted roles to
control database permissions.
As a sanity test -
On Thu, Mar 27, 2014 at 3:51 AM, Stuart Bishop
stuart.bis...@canonical.com wrote:
In effect it looks like I don't need to share the credentials among
the services?
Correct. I think you are just fine with one relation per database and
using the generated credentials, and using the granted
On Tue, Mar 25, 2014 at 12:07 PM, Stuart Bishop
stuart.bis...@canonical.com wrote:
The patch would be like: GRANT DELETE ON TABLE person TO landscape.
That landscape is hardcoded, so that user has to exist and be the
user the services use. So your first paragraph above solves this
already,
On 25 March 2014 19:47, Andreas Hasenack andr...@canonical.com wrote:
On Tue, Mar 25, 2014 at 7:51 AM, Stuart Bishop stu...@stuartbishop.net
wrote:
The simple fix is to add a usernames or extra_usernames parameter on
the relation, similar to database, allowing the client to specify a
list
On Mon, Nov 4, 2013 at 7:50 AM, Stuart Bishop
stuart.bis...@canonical.com wrote:
On Tue, Oct 29, 2013 at 7:38 PM, Andreas Hasenack andr...@canonical.com
wrote:
When the first unit of the app comes up, it creates a random password and
uses the DB admin user to create an unprivileged DB user
On Tue, Oct 29, 2013 at 7:38 PM, Andreas Hasenack andr...@canonical.com wrote:
When the first unit of the app comes up, it creates a random password and
uses the DB admin user to create an unprivileged DB user with that password.
Do you know why the client service needs to create the user,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/10/13 17:12, Kapil Thangavelu wrote:
fwiw, the mysql charm tries to address this with a shared-db
interface, and a separate admin interface. ie the shared-db
interface shares out the same db user/password to multiple
services, and then for
On Wed, Oct 30, 2013 at 10:47 AM, Gustavo Niemeyer gust...@niemeyer.netwrote:
On Wed, Oct 30, 2013 at 7:35 AM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
Just thinking outloud, but In the active-active db scenario, there's an
available db for the charm to store this info. ie.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-10-29 16:38, Andreas Hasenack wrote:
Hi,
There is this charm with a db-admin relation to postgresql. In
this relation, the charm gets access to a super user in postgresql
and can do whatever it wants with it.
When the first unit of
On Tue, Oct 29, 2013 at 11:11 AM, John Arbash Meinel j...@arbash-meinel.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-10-29 16:38, Andreas Hasenack wrote:
Now I run add-unit, and another unit comes up. How can it get that
password?
...
Is this a case for a peer
12 matches
Mail list logo
