-
Notifications
You must be signed in to change notification settings - Fork 614
Resolve dependencies to the databases automatically #963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
72b65fb
to
053a555
Compare
@hasegeli Your changes are currently causing failures in the grant_spec acceptance test's on lines 98 and 110. Please fix this before it can be merged. |
ab56e5e
to
795180e
Compare
Could you please retrigger the tests? |
@hasegeli I've closed and opened the PR. The test's should show fine now. |
5c1c51e
to
6ebd78c
Compare
In #950 I also do a lot of dependency chaining like this. Could anyone have a look at what would be the better approach? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this and #950 are both complementary.
@@ -4,7 +4,6 @@ | |||
$password_hash = false, | |||
$createdb = false, | |||
$createrole = false, | |||
$db = $postgresql::server::default_database, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This parameter is considered public API and removing it would be breaking, even if it doesn't actually do anything. If the db param is not needed then we could just make it unused and deprecated it, and remove it later.
Does the database specified not affect the ALTER ROLE
commands below? Are roles always defined globally and not db-specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes roles are always global on Postgres. This option was also not documented. I find it hard to believe anyone would search and find the argument that does nothing. Should we still keep it and emit a warning()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting that it was not documented. Yes, I think it should still be kept and just emit a warning and do nothing. It has been there ever since postgresql::server::role
was created in 2013 and even before that for postgresql::role
. And it's in the acceptance tests. I'm sure there are people using it for years :.
This needs a rebase now. |
Have you seen the comment
Do you know how to implement it inside |
I think I implemented this in d69ff1e but please verify this. |
Yes, we need the same but against a resource not a class. Do you know how to do it? This is how its done on Puppet:
|
I think this would be in autorequire like: autorequire(:postgresql_psql) do
["CREATE DATABASE #{self[:db]}"]
end |
This would be the same as the current coding. Although it would be better if we could rely on the whole
|
This option doesn't make sense, because roles are not specific to databases on PostgreSQL. It was not documented on the README, so I don't see value in making this backwards compatible.
Hello, we have been using your submodle for a while and we are currently having an issue |
@hasegeli I am know closing this as you had previously mentioned in another PR that you had finished working with Puppet. I would like to once again state how sorry I am to hear that, and hope to one day hear from you again in the future. |
No description provided.