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

swap: add ReportIO option #814

Merged
merged 1 commit into from
Jun 15, 2018
Merged

Conversation

sileht
Copy link
Contributor

@sileht sileht commented Jun 5, 2018

swap: add ReportIO option

Add the new ReportIO option of collectd 5.8.

Add the new ReportIO option of collectd 5.8.
@@ -6,13 +6,14 @@
Boolean $reportbytes = true,
Boolean $valuesabsolute = true,
Boolean $valuespercentage = false,
Boolean $reportio = true,
Copy link
Member

@juniorsysadmin juniorsysadmin Jun 6, 2018

Choose a reason for hiding this comment

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

For new options, I personally would prefer that they be Optional[Boolean] so that backward compatibility is preserved and we can eventually drop all of the if collected::version conditional logic. This does mean that you need to use something like == undef or defined() in templates though.

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 I'm lost, I have done that in the past and I have been asked to do the reverse #800 (comment)

Can you see with @bastelfreak what you really want before I go further.

Copy link
Member

Choose a reason for hiding this comment

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

From our review guide:

Are there new params with datatype Boolean? The default value is a tricky decision which needs careful reviewing. Sometimes a True/False is the better approach, sometimes undef

From an interface perspective it isn't a breaking change because the new parameter has a default value. Also it isn't written directly to the config file, only if collectd has the correct version, so the behavior isn't a breaking change either.


Instead of the collectd version check we could ensure it isn't undef. I'm not sure if we gain much when the parameter is undef. I'm a bit unsure here and would like to get more feedback from others.

Copy link
Member

Choose a reason for hiding this comment

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

@sileht There's a few inconsistencies in this module and I'm refactoring large parts of it at the moment. Another thing that comes to mind is application defaults versus the defaults in this module. For instance, if the application default behaviour if the value is not in the configuration file is true, should this module explicitly put in the value in there? If so, what should happen in this module when a newer version of collectd does a breaking change switching the default behaviour to true/false?

Anyway, these consistency changes can be done as a separate Pull Request, so I am merging this for now.

@juniorsysadmin juniorsysadmin added the enhancement New feature or request label Jun 6, 2018
@juniorsysadmin juniorsysadmin merged commit e676a9e into voxpupuli:master Jun 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants