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

feat: Implement deprecation infrastructure #9857

Closed
wants to merge 47 commits into from

Conversation

srebhan
Copy link
Member

@srebhan srebhan commented Oct 4, 2021

Required for all PRs:

  • Updated associated README.md.
  • Wrote appropriate unit tests.
  • Pull request title or commits are in conventional commit format (e.g. feat: or fix:)

relates to #9478

This PR adds the possibility to deprecate plugins in a machine-readable form by adding an entry to the deprecations.go file in the plugin category (e.g. inputs). This entry needs to at least contain the version since when the plugin was deprecated and a notice for the user e.g. suggesting replacements. Furthermore, you can also deprecate plugin config-options by adding a deprecated tag like

	Address         string   `toml:"address" deprecated:"1.12.0;use 'urls' instead"`

also providing a "since" version and a hint separated by a colon.
Both, plugin and option deprecation, can also specify a 'removal in' version, specifying the version when removal of the plugin or option is planned. For the deprecated tag you simply add it as a second version after since, e.g.

	Address         string   `toml:"address" deprecated:"<since>;<removal in>;<note for the user>"`

The new framework is then used to print deprecation warnings (or errors) during startup of telegraf or to print a list of deprecated options or plugins via telegraf --deprecation-list.

@telegraf-tiger telegraf-tiger bot added the feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin label Oct 4, 2021
Copy link
Contributor

@powersj powersj left a comment

Choose a reason for hiding this comment

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

This is pretty sweet, thanks for putting this together. I have some high-level comments about what this looks like below. Thanks again!

Makefile Show resolved Hide resolved
config/deprecation.go Outdated Show resolved Hide resolved
config/deprecation.go Show resolved Hide resolved
config/deprecation.go Outdated Show resolved Hide resolved
cmd/telegraf/telegraf.go Outdated Show resolved Hide resolved
@Hipska
Copy link
Contributor

Hipska commented Oct 7, 2021

Adding an information message here if user uses deprecated options/plugins would be nice:

log.Printf("I! Loaded inputs: %s", strings.Join(c.InputNames(), " "))
log.Printf("I! Loaded aggregators: %s", strings.Join(c.AggregatorNames(), " "))
log.Printf("I! Loaded processors: %s", strings.Join(c.ProcessorNames(), " "))
log.Printf("I! Loaded outputs: %s", strings.Join(c.OutputNames(), " "))
log.Printf("I! Tags enabled: %s", c.ListTags())

(This will go into any configured logfile, instead of the pre-config-completely-loaded stdout/stderr messages)

@srebhan srebhan requested a review from Hipska October 13, 2021 13:20
@Hipska
Copy link
Contributor

Hipska commented Oct 14, 2021

You might also update docs/COMMANDS_AND_FLAGS.md

@srebhan
Copy link
Member Author

srebhan commented Oct 14, 2021

@Hipska good catch. Done.

docs/COMMANDS_AND_FLAGS.md Outdated Show resolved Hide resolved
@Hipska Hipska added the ready for final review This pull request has been reviewed and/or tested by multiple users and is ready for a final review. label Oct 14, 2021
Copy link
Contributor

@powersj powersj left a comment

Choose a reason for hiding this comment

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

@srebhan,

@reimda and I were talking through this during pairs. One of the scenarios we ran across is what happens when a plugin is removed. When we remove a plugin it would be nice to be able to remove the source code and delete it from the all.go file and be done with it. As this is currently written, we would need to keep the plugin around for the deprecation code to get called.

Also, a similar question for the removal of fields. In order to finally remove the field but also notify the user, how will this work without leaving the field in?

Dave and I tried to fake this with a _ or a _foobar and neither worked as we expected. Have you tried this out?

Thanks!

@srebhan
Copy link
Member Author

srebhan commented Oct 22, 2021

@powersj, @reimda I'm not sure I do understand your examples. IMO a plugin/plugin option is deprecated in a certain version (e.g. 1.20). In this example I do expect the user to receive a warning starting from version 1.20 on. The next step is, after a grace time of e.g. 4 minor updates (>=1.24) or one major + 4 minor (>= 2.4), the warning turns into an error (we might want to allow starting nonetheless with a cmdline switch or similar). Now, maybe after another gracetime (e.g. >= 1.28 or 2.8) the plugin or option can be removed at any time without further notice.
The time-periods are subject to discussion, but in the example that would give a user ~1 year from deprecation to react to the warning and another ~year to override the error. So in total a user has ~2 years to migrate...

Of course the deprecation warning is then gone when the plugin or plugin option is removed, but that's correct as there is no deprecated plugin/option any longer. What am I missing here? Is your intention to remove the plugin/plugin option and still get a warning? If so why? A plugin removed will trigger config errors, so there is no silent fail anyway...

@srebhan srebhan removed the ready for final review This pull request has been reviewed and/or tested by multiple users and is ready for a final review. label Nov 9, 2021
plugins/inputs/deprecations.go Outdated Show resolved Hide resolved
config/config.go Outdated Show resolved Hide resolved
config/deprecation.go Outdated Show resolved Hide resolved
config/deprecation.go Show resolved Hide resolved
config/deprecation.go Show resolved Hide resolved
@telegraf-tiger
Copy link
Contributor

@sspaink sspaink mentioned this pull request Nov 11, 2021
2 tasks
Copy link
Contributor

@powersj powersj left a comment

Choose a reason for hiding this comment

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

This is looking awesome! I have some questions and one issue when trying this out setting the build_version to 2.0.0.

config/config.go Show resolved Hide resolved
plugins/inputs/deprecations.go Outdated Show resolved Hide resolved
config/deprecation.go Outdated Show resolved Hide resolved
config/deprecation.go Show resolved Hide resolved
config/deprecation.go Show resolved Hide resolved
config/deprecation.go Outdated Show resolved Hide resolved
config/deprecation.go Show resolved Hide resolved
go.mod Outdated Show resolved Hide resolved
…s a (indirect) dependency."

This reverts commit 184d745.
@srebhan srebhan requested a review from powersj November 22, 2021 07:42
@telegraf-tiger
Copy link
Contributor

@Hipska Hipska added the ready for final review This pull request has been reviewed and/or tested by multiple users and is ready for a final review. label Nov 22, 2021
Copy link
Contributor

@powersj powersj left a comment

Choose a reason for hiding this comment

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

+1 - need Dave to sign off, so that will happen early next week. I do know that he will probably comment on the behavior of when RemovalIn is not set. I think his desire, and I agree with it, is that we are explicit anytime we deprecate a plugin and that means setting the RemovalIn value.

@Hipska
Copy link
Contributor

Hipska commented Nov 23, 2021

Just stumbled on this; What about deprecation of agent/global config options?

@srebhan
Copy link
Member Author

srebhan commented Nov 23, 2021

@Hipska this is out of scope for this PR. Getting this to the current state was already a lot of (non-technical) discussions and decision-making, so I suggest to postpone more features to future PRs.
Anyway, this will not be a standard mechanism and probably needs a manual source of information...

@srebhan
Copy link
Member Author

srebhan commented Nov 23, 2021

@powersj if requiring a RemovalIn is already "set in stone" I can implement it before Dave's review... :-)

However, I also want you to consider developers trying to deprecate things. Currently, it is possible but not mandatory to set the RemovalIn field, so a developer providing a replacement can add a "deprecation" which says, starting from "x.y.z" you better use the new plugin, leaving the removal "open" to the default next possible date. You can then postpone this date for any reason. The question now is, what is the default. Will you always want to set a custom version for the removal? This means you need to tell the developer in the PR what to put into the RemovalIn field. Or do you never want the dev to deprecate the "old" plugin?

@reimda
Copy link
Contributor

reimda commented Dec 1, 2021

@srebhan Could you resolve the conflict? Otherwise it's ready to merge.

@reimda
Copy link
Contributor

reimda commented Dec 1, 2021

I fixed the conflict in #10200 and merged it. Closing this. Thanks @srebhan for the PR!

@reimda reimda closed this Dec 1, 2021
@srebhan srebhan deleted the deprecation branch December 2, 2021 08:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/agent feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin ready for final review This pull request has been reviewed and/or tested by multiple users and is ready for a final review.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants