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

Add explicit parameter types to all parameters #1189

Closed

Conversation

JacobHenner
Copy link
Contributor

This is a WIP to specify parameter datatypes where missing, and reconsider some potentially inconsistent types.

@JacobHenner JacobHenner force-pushed the add_parameter_types branch from b21e1b2 to a06ecf8 Compare March 15, 2018 03:07
@JacobHenner
Copy link
Contributor Author

JacobHenner commented Mar 15, 2018

As I continue to work through this, I notice that there are a bunch of odd situations that should probably discussed.

  • Intermingling boolean and 'on'/'off' strings.
  • Strings being used for some fields that could use integers, but not others
  • The implicit use of Enum['opt 1', 'opt 2', false] rather than Optional[Enum['opt1 ', 'opt 2']
  • Optional[Boolean]

I'll add examples in contextual comments once I get my branch passing unit tests.

@ekohl
Copy link
Member

ekohl commented Mar 15, 2018

In #1155 I started doing the same. Could be good to align the two.

@JacobHenner
Copy link
Contributor Author

JacobHenner commented Mar 15, 2018 via email

@ekohl
Copy link
Member

ekohl commented Mar 15, 2018

For now I added the backwards-incompatible label because I don't know if any type changed. This may not be true and we could remove it later. I'd be happy to change some parameters so the types are consistent and parameters aligned.

As I continue to work through this, I notice that there are a bunch of odd situations that should probably discussed.

I noticed those as well when I started to work on it. I'd be happy if we could be consistent.

@JacobHenner
Copy link
Contributor Author

Pending #1190 and #1191 (to confirm the final failing spectest isn't related to this change).

After confirmation, I'll comment on the individual changes and seek consensus for the ambiguous/poorly typed parameters.

@JacobHenner JacobHenner force-pushed the add_parameter_types branch from 1631dc2 to 60b171b Compare March 17, 2018 13:19
@JacobHenner
Copy link
Contributor Author

Now that #1190 is fixed, it looks like all tests are passing. When I have some time (hopefully this weekend), I will comment on the cases that should be discussed.

@bastelfreak bastelfreak added the needs-work not ready to merge just yet label Mar 17, 2018
@JacobHenner
Copy link
Contributor Author

One pattern I've noticed a bunch of times is the use of strings "on" and "off" to match nginx's config representation, rather than booleans. Do we want to standardize these values, and restrict these parameters to Enum["on","off"], or should a breaking change be introduced to set these as boolean parameters?

@ekohl
Copy link
Member

ekohl commented Mar 20, 2018

That's something I've struggled with as well. I believe there are option that accept on, off and others which would argue in favor of the Enum solution. For now I've followed that, but I'd be open to other solutions.

@JacobHenner
Copy link
Contributor Author

Is there any consensus on whether Enums with ["on","off"], booleans, or the current hybrid of the two and the optional type should be used? Since this will be a breaking change, I want to make sure there's some agreement before standardizing it one way or another.

@JacobHenner JacobHenner force-pushed the add_parameter_types branch 6 times, most recently from 1b08230 to 72f4f98 Compare April 4, 2018 03:00
@JacobHenner JacobHenner force-pushed the add_parameter_types branch from 72f4f98 to cfed312 Compare April 14, 2018 12:19
@JacobHenner JacobHenner reopened this Apr 21, 2018
@JacobHenner JacobHenner changed the title WIP: Add explicit parameter types to all parameters Add explicit parameter types to all parameters Apr 21, 2018
@JacobHenner
Copy link
Contributor Author

I believe this is ready for review and discussion.

@JacobHenner JacobHenner force-pushed the add_parameter_types branch from cfed312 to 1a30582 Compare April 21, 2018 02:04
Optional[String[1]] $daemon_group = undef,
String[1] $global_owner = $::nginx::params::global_owner,
String[1] $global_group = $::nginx::params::global_group,
Stdlib::Filemode $global_mode = $::nginx::params::global_mode,
Copy link
Member

Choose a reason for hiding this comment

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

great that we finally have a datatype for this

Copy link
Member

Choose a reason for hiding this comment

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

Can you, in a seperate PR, bump the stdlib requirement to at least 4.22.0 in metadata.json?

2018-04-21-205849_608x197_scrot

Variant[String[1], Boolean] $pid = $::nginx::params::pid,
String[1] $proxy_temp_path = $::nginx::params::proxy_temp_path,
String[1] $root_group = $::nginx::params::root_group,
String[1] $run_dir = $::nginx::params::run_dir,
Copy link
Member

Choose a reason for hiding this comment

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

We can you Stdlib::Absolutepath here?

@@ -300,10 +300,10 @@
# Check to see if SSL Certificates are properly defined.
if $ssl {
if $ssl_cert == undef {
fail('nginx: ssl_cert must be set to false or to a fully qualified path')
warning('nginx: ssl enabled but ssl_cert undef')
Copy link
Member

Choose a reason for hiding this comment

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

why did you change this? Doesn't a fail() make more sense?

@JacobHenner JacobHenner force-pushed the add_parameter_types branch from 1a30582 to 3677b16 Compare April 21, 2018 19:29
Optional[String[1]] $proxy = undef,
Nginx::Duration $proxy_read_timeout = $::nginx::proxy_read_timeout,
Nginx::Duration $proxy_connect_timeout = $::nginx::proxy_connect_timeout,
Array[String[1]] $resolver = [],
Copy link
Member

Choose a reason for hiding this comment

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

now resolver is a required parameter, it needs to contain a string, this wasn't the case before. Should we change it back?

@JacobHenner JacobHenner force-pushed the add_parameter_types branch from 8f12b01 to 24f7831 Compare June 1, 2018 01:51
@JacobHenner
Copy link
Contributor Author

Is there still interest in this?

@bastelfreak
Copy link
Member

There sure is! I raised a few inline questions within the code, can you take a look? In the meantime we also defined some guidelines for a consistent code style: https://voxpupuli.org/docs/#reviewing-a-module-pr

@ekohl
Copy link
Member

ekohl commented Oct 1, 2018

To get this merged I think it's easier if we split this up into manageable pieces. Would you be willing to submit a PR per file?

@bastelfreak
Copy link
Member

Ping @JacobHenner :)

@vox-pupuli-tasks
Copy link

Dear @JacobHenner, thanks for the PR!

This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase?

You can find my sourcecode at voxpupuli/vox-pupuli-tasks

1 similar comment
@vox-pupuli-tasks
Copy link

Dear @JacobHenner, thanks for the PR!

This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase?

You can find my sourcecode at voxpupuli/vox-pupuli-tasks

@vox-pupuli-tasks
Copy link

Dear @JacobHenner, thanks for the PR!

This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase?

You can find my sourcecode at voxpupuli/vox-pupuli-tasks

@vox-pupuli-tasks
Copy link

Dear @JacobHenner, thanks for the PR!

This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase?

You can find my sourcecode at voxpupuli/vox-pupuli-tasks

@ekohl
Copy link
Member

ekohl commented Aug 30, 2020

Replacement in #1413

@ekohl ekohl closed this Aug 30, 2020
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.

5 participants