Skip to content

Conversation

@philipwigg
Copy link

The defined function used to set $puppetdb_port as originally used doesn't work here, the default of 8081 is set no matter what. Switching to defined(Class['puppetdb']) seem to fix that.

Also, because the use_ssl parameter in the puppetdb_conn_validator resource is false only if the puppetdb_port is 8080, you can't set a different port using ::puppet::config::puppetdb_port without also setting use_ssl to true which might not be what you want.

I've added an extra parameter puppetdb_disable_ssl to the class so that when the Puppet Master and the PuppetDB are on separate servers you can still set a non-standard puppetdb_port whilst using plain HTTP.

I'm still not sure the logic we're using here is that good though but it is hopefully an improvement.

@kbarber
Copy link
Contributor

kbarber commented Oct 7, 2014

@philipwigg without thinking about this too hard ... won't this break some users prior assumptions? That is, this patch looks like it might be a breaking change. For good or worse, this affects how we ship it. Am I incorrect? If not can we manipulate this to keep some semblance of backwards compatibility?

@philipwigg
Copy link
Author

Err.. there are a few bits to this but I'm not sure anyone of the changes will break anything.

Let's take it one part at a time.

This is how $puppetdb_port parameter is set currently:-

$puppetdb_port = defined('$puppetdb::disable_ssl') ? { true => $puppetdb::disable_ssl ? { true => 8080, default => 8081, }, default => 8081, }, 

I don't think this ever works. Some test code:-

class puppetdb( $disable_ssl = true ) { } class puppetdb::master( $puppetdb_port = defined('$puppetdb::disable_ssl') ? { true => $puppetdb::disable_ssl ? { true => 8080, default => 8081, }, default => 8081, }, ) { notify { "$puppetdb_port": } } class { 'puppetdb': } class { 'puppetdb::master': require => Class['puppetdb'] } 

puppet apply test.pp returns 8081, but it should be 8080 right?

@kbarber
Copy link
Contributor

kbarber commented Oct 8, 2014

Yeah, looks like you are correct. Weird defined doesn't do what we expect, but oh well.

I've merged this in manually as it needed a rebase, squashed your commits and reworded the commit message a tad.

Thanks @philipwigg.

@kbarber kbarber closed this Oct 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants