-
Notifications
You must be signed in to change notification settings - Fork 612
(MODULES-3319) Hash argument for create_resources #775
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
Was #765 |
@jcpunk, it seems that the vendor modules are lint-checked and some fail. Could you review this and re-trigger the build? I'm highly interested in seeing your pull request being merged. |
hmmm.... I'm a bit concerned to merge puppet-lint fixes in with this patch. I'll see about getting another PR opened up to fix the linting issues. |
@jcpunk, ah sorry, I should have expressed that more precisely. What I meant is, that in your pull request the vendor-modules are lint-checked. In your pull request this fix has not been merged yet. I think after merging/rebasing against the master your PR should be fine. |
Ahh, got it. I've rebased off of master and pushed again. |
I re-kicked travis, the lint issues are gone. Now there are just test failures.
|
hmmmm.... I have no idea why the client_spec tests are failing.... Any suggestions? |
:package_name => 'mypackage', | ||
:file_ensure => 'file', | ||
:validate_connections => { :test => { | ||
:database_host => 'test', |
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.
Try changing symbols to strings throughout this validate_connections hash, like you've got in server_spec.rb. I don't think rspec-puppet can convert hash keys properly in a manifest.
Gave it a shot and pushed it up. |
The rspec-tests are running fine now but there seems something wrong with the connection to the docker-containers in the beaker-tests. |
Without this patch, seperate modules and classes need to be built to declare the provided defines for the postgresql server. This patch permits the passing of a hash into the postgresql::server function for the various resources. The puppetlabs-mysql module provides similar behavior whereby databases can be managed as values from Hiera or an ENC. This commit brings the puppetlabs-postgresql module into feature parity with the puppetlabs-mysql module.
@jcpunk Could you please rebase on current master and see if the beaker-tests run through now? |
Conflicts: manifests/server/schema.pp
Attempted rebase |
👍 |
@bmjen Would you mind merging this PR? |
Hi @jcpunk @gerhardsam we spent time discussing this PR in the community meeting. This is not a simple merge. Our notes are here, https://github.com/voxpupuli/community-triage/blob/master/modules/notes/2016-07-28.md#discussion it would be great if you could come to the community meeting next week to discuss it further. It is on Thursdays -17:00 UTC, @ http://bluejeans.com/280736660 |
Unfortunately I've got a weekly meeting that conflicts. Is there a pointer to some doc that could bring me up to speed on "adoption of proper profile-level abstraction practices"? |
FWIW, issues like this have been discussed in the past. Here are a few PRs I remember because I participated in the discussion: #465, #467, puppetlabs/puppetlabs-apache#794, puppetlabs/puppetlabs-haproxy#172 In the cases above others and I argued that the way to go was not including Hiera support in the module but to encourage abstraction, like profile or wrapper modules. AFAIK there has never been an official statement or stance on this topic from Puppetlabs, so maybe this is an opportunity. An example of Hiera support "going too far" is, IMHO, presented in voxpupuli/puppet-php#160. In that module/class it is impossible to set various parameters without using Hiera, and trying to refactor the module in that regard has been a nightmare on which I quickly had to give up. The coupling between Puppet code and Hiera is just way too tight. |
There is no documentation on this as yet. I have created https://tickets.puppetlabs.com/browse/MODULES-3661 for investigation work. That is not to say that is something we are starting immediately. |
@tphoney Thanks for the invitation. I'm not sure, whether I'm able to attend the meeting. I try to, but i cannot guarantee it. |
@tphoney Unfortunatly I'm not able to attend the meeting. Please Informationen me about the results of your discussion. |
$schemas = {}, | ||
$table_grants = {}, | ||
$tablespaces = {}, | ||
|
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.
Instead of adding a lot of extra hash parameters that are implicitly for hiera or ENC use, what about making this a bit more explicit? eg:
class postgresql::profile::hiera (
$config_entries = {},
$databases = {},
$database_grants = {},
$dbs = {},
$extensions = {},
$pg_hba_rules = {},
$pg_ident_rules = {},
$recovery = {},
$roles = {},
$schemas = {},
$table_grants = {},
$tablespaces = {},
) {
create_resources('postgresql::server::config_entry', $config_entries)
create_resources('postgresql::server::database', $databases)
create_resources('postgresql::server::database_grant', $database_grants)
create_resources('postgresql::server::db', $dbs)
create_resources('postgresql::server::extension', $extensions)
create_resources('postgresql::server::pg_hba_rule', $pg_hba_rules)
create_resources('postgresql::server::pg_ident_rule', $pg_ident_rules)
create_resources('postgresql::server::recovery', $recovery)
create_resources('postgresql::server::role', $roles)
create_resources('postgresql::server::schema', $schemas)
create_resources('postgresql::server::table_grant', $table_grants)
create_resources('postgresql::server::tablespace', $tablespaces)
}
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.
The related discussion to come up with this pattern is in https://github.com/voxpupuli/community-triage/blob/master/modules/notes/2017-03-02.md . tl;dr is that "this isn't a great pattern to be stuck on, but it seems like most people still have to move through it before they arrive at profile abstraction patterns so how can we facilitate that path of learning?"
Closing this due to inactivity. If this is still something you'd like to see merged, please feel free to re-open. |
Without this patch, seperate modules and classes need to be built
to declare the provided defines for the postgresql server.
This patch permits the passing of a hash into the postgresql::server
function for the various resources.
The puppetlabs-mysql module provides similar behavior whereby
databases can be managed as values from Hiera or an ENC. This
commit brings the puppetlabs-postgresql module into feature
parity with the puppetlabs-mysql module.