Skip to content
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

Improve/silence warning from pull-request #2154 #2160

Closed
wants to merge 2 commits into from

Conversation

sircubbi
Copy link
Contributor

Hi,

pull-request #2154 did try to silence the warnings about servernames and filenames to cases where a problem actually exists.

However, there are two problems with that:

  1. there is a check between "name" and "normalized_servername", when it actually should check for differences between "servername" and "normalized_servername".

  2. even if that check is silenced, there is still the second warning about "use_port_for_filenames" not enabled. That warning should only be issued if "use_servername_for_filenames" is enabled.

…filename

silences warnings to "real" cases, as it was intended with pull-request
2154
@sircubbi sircubbi requested a review from a team as a code owner June 22, 2021 14:49
@CLAassistant
Copy link

CLAassistant commented Jun 22, 2021

CLA assistant check
All committers have signed the CLA.

@puppet-community-rangefinder
Copy link

apache::vhost is a type

Breaking changes to this file WILL impact these 128 modules (exact match):
Breaking changes to this file MAY impact these 34 modules (near match):

This module is declared in 175 of 576 indexed public Puppetfiles.


These results were generated with Rangefinder, a tool that helps predict the downstream impact of breaking changes to elements used in Puppet modules. You can run this on the command line to get a full report.

Exact matches are those that we can positively identify via namespace and the declaring modules' metadata. Non-namespaced items, such as Puppet 3.x functions, will always be reported as near matches only.

Copy link
Collaborator

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must admit in reviewing this that I'm not entirely sure the whole deprecation for version 8 is that good of an idea. For example, I'm not looking forward to it. It's really a mess when upgrading.

For us the impact of removing use_port_for_filenames would be a lot less when it would not use the port if it's default (80 for http, 443 for https).

@@ -2111,7 +2111,7 @@
false => $name,
}

if ! $use_servername_for_filenames and $name != $normalized_servername {
if ! $use_servername_for_filenames and $servername != $normalized_servername {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks correct to me. I guess in my testing I didnt' specify a servername so they happened to match.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, I'm reading this again and what I based it on was this part:

$filename = $use_servername_for_filenames ? {
true => $use_port_for_filenames ? {
true => regsubst("${normalized_servername}-${port}", ' ', '_', 'G'),
false => regsubst($normalized_servername, ' ', '_', 'G'),
},
false => $name,
}

So right now it uses $name for $filename, but after it will use $normalized_servername which is a change. Maybe I should have done it otherwise and determined $v8_filename instead and compared that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, as I see now the check between $name/$normalized_servername and between $servername/$normalized_servername are both bogus in that case.

While I see no problem at all to use a normalized-servername as the filename for the apache-configsnipped, I understand the reasoning in rolling that change in stages and issue warnings.

However, I really would like to have a possibility to "defuse" these warnings on a global level. While still messy, maybe we could lookup the $use_servername_for_filenames and $use_port_for_filenames from hiera? In that case it would be at least possible to enable both parameters on one place.

@@ -2122,7 +2122,7 @@
module, the $use_servername_for_filenames will be removed and log/config file names will be derived from the
sanitized $servername parameter when not explicitly defined.'
warning($use_servername_for_filenames_warn_msg)
} elsif ! $use_port_for_filenames {
} elsif $use_servername_for_filenames and ! $use_port_for_filenames {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look correct to me. I think the intention is to warn users ahead of time that they'll run into problems in the future.

Copy link
Contributor Author

@sircubbi sircubbi Jun 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand. However, I am not sure about the correct usage then. Most vhosts-definitions I have here are actually two definitions for the same servername (the non-ssl version, and the ssl-version).
As for now every puppet run fills the log with that warnings, and the only way to get rid of them is by enabling the $use_port_for_filenames parameter. However I am not really sure if it is a good idea to enable that parameter, since it is scheduled to be deprecated with the next releases.

What would be a proper way to declare two vhosts for the same servername without getting the warning?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I think you have the same problem as I started with. Personally I'd like the whole deprecation not to happen and instead remain compatible as much as possible.

I think the best way for that is to only include the port if it's non-default. I tried to come up with a patch and I think #2161 might do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As already mentioned on #2161 that would not help if you need the same servername for a ssl and a non-ssl version. At least one filename has to be prefixed or suffixed with the protocol. But then using the portname seems to be much more appropriate.

@elofu17
Copy link

elofu17 commented Sep 23, 2021

I'm annoyed by the logged message, logged over and over, from every puppet node with apache, for each puppet run.
All nodes are configured as standard as possible, so I don't think I need to see the warnings all the time.

  class { 'apache':
  }
  apache::vhost { $::fqdn:
    port    => 80,
    docroot => "/var/www/${::fqdn}",
  }

This result in e.g.:

2021-09-23 18:41:07,692 WARN  [puppetserver] Scope(Apache::Vhost[foobar.infra.gazonk.com])
    It is possible for multiple virtual hosts to be configured using the same $servername but a different port. When
    using $use_servername_for_filenames, this can lead to duplicate resource declarations.
    When $use_port_for_filenames = true, the $servername and $port parameters, sanitized, are used to construct log and
    config file names.

    From version v7.0.0 of the puppetlabs-apache module, this parameter will default to true. From version v8.0.0 of the
    module, the $use_port_for_filenames will be removed and log/config file names will be derived from the
    sanitized $servername parameter when not explicitly defined.

With only one port, there's no risk for duplicate declarations.
With my standard code, I should see no warnings/instructions at all -- they just confuse me.

The current defaults in v6 should be enough.
The defaults in v7 and v8 should be also be enough.
That is,. I should not need to do any changes to my code during this transition, neither add
use_port_for_filenames = true nor remove it in v8.
Therefore I should not be spammed with annoying warnings/instructions.

@zilchms
Copy link

zilchms commented Jan 10, 2022

Any updates on this? Filling the puppet server log with these warnings, while the underlying "space in name" and deprecation problem is not present in the configured resources, seems a bit much. As i get from the discussion between @ekohl and @sircubbi there seems to be no "nice" way to fix this, is there? Can i help with anything there (would need some time to get into the code)?

@github-actions
Copy link

This PR has been marked as stale because it has been open for a while and has had no recent activity. If this PR is still important to you please drop a comment below and we will add this to our backlog to complete. Otherwise, it will be closed in 7 days.

@github-actions github-actions bot added the stale label Apr 26, 2022
@github-actions github-actions bot closed this May 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants