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

gitlab_monitor got renamed to gitlab_exporter in 12.3 #323

Closed
baurmatt opened this issue Sep 24, 2019 · 4 comments · Fixed by #324
Closed

gitlab_monitor got renamed to gitlab_exporter in 12.3 #323

baurmatt opened this issue Sep 24, 2019 · 4 comments · Fixed by #324

Comments

@baurmatt
Copy link
Contributor

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: All
  • Ruby: All
  • Distribution: All
  • Module version: Current

How to reproduce (e.g Puppet code you use)

Read changelog ;) --> https://docs.gitlab.com/omnibus/update/gitlab_12_changes.html#123

Deprecated. Will be removed in 13.

What are you seeing

gitlab_exporter got renamed to gitlab_monitor.

What behaviour did you expect instead

sys11gitlab::gitlab_exporter should be available

Output log

Any additional information you'd like to impart

@baurmatt
Copy link
Contributor Author

I'm not sure how we handle deprecated/renamed parameters. Just add an additional parameter gitlab_exporter and throw a warning() for sys11gitlab::gitlab_monitor?

Happy to implement this after we figured out how to handle the deprecation! :)

@LongLiveCHIEF
Copy link
Contributor

We've had similar issues come up a few times before. (Hence the section in the README about what major/minor versions this puppet module targets for support).

The suggestion you had is one approach we've used, and that works well. (In the past I think we used a notify resource, but the last time this happened we were still only supporting puppet 3/4).
For an example, check out how we handled the change of the skip_auto_migrations config key to skip_auto_reconfigure (see: #234 )

The other approach we've used is to coerce one setting into another, like we did with the edition parameter this module used to support. (see manifests/install.pp)

The first case is used when gitlab changes or removes a parameter, and the latter is used when we deprecate or remove a parameter that was exclusive to this module.

@LongLiveCHIEF
Copy link
Contributor

@baurmatt hope those examples help. I'll keep an eye out to review PR's if you decide to take a shot at it yourself.

If you'd rather me do it, just say the word and I'll update and try to release over the weekend.

baurmatt added a commit to syseleven/puppet-gitlab that referenced this issue Sep 25, 2019
baurmatt added a commit to syseleven/puppet-gitlab that referenced this issue Sep 25, 2019
@baurmatt
Copy link
Contributor Author

Hey @LongLiveCHIEF, thanks for taking a look and pulling out those examples! :) I've tried to implemented it as close as possible to the first PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants