-
Notifications
You must be signed in to change notification settings - Fork 260
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
Puppet v4 upgrade #362
Puppet v4 upgrade #362
Conversation
Add more versions for supported OSes
Any plans to merge this PR? |
@bittner I would love to merge this as it would clearly help us cleanup.... I'm not 100% sure off-hand but I think this would break for older puppets. We're trying to keep backward compatibility in this But this would certainly be valuable for the next major module release which would in all likelihood be puppet 4+ compatible only. |
You're not sure. That's one thing. We're all sure that the current implementation breaks for newer Puppets, though. That is real. |
@bittner could you be more specific as to what version this breaks in. I'm not saying we're not going to merge this, I'm saying there's stuff in there that could break for some of our users. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should definitely add the new operating system release versions and release an updated module as soon as possible. I have reservations regarding system_gem
though.
"version_requirement": ">=2.2.0 <5.0.0" | ||
}, | ||
{ | ||
"name": "tkishel/system_gem", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This right here is my main concern. See: https://github.com/tkishel/system_gem/blob/master/metadata.json#L24-L28
It's not supported for a bunch of puppet versions we do support, so I guess that's a no-no for now. I understand it addresses an important issue on windows.
"12.04", | ||
"14.04" | ||
] | ||
"operatingsystemrelease": ["10.04", "12.04", "14.04", "16.04", "17.04", "17.10"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've only officially supported LTS versions thus far - we should probably stay consistent with that (for now)
How "more specific" can we be than referencing 3 specific issues that contain the details that motivate these changes?
When you look at all the other issues and PRs where you say similar things please understand that DataDog users are getting frustrated with the support DataDog is providing for their closed-source platform. We, the "community", are doing free maintenance of this module and all DataDog employees are capable of is saying, "no, this is not going to be merged". Find a solution that is better than ours. Give suggestions on how to change the PR so that it also covers all your concerns. Start writing or suggest more tests, extend the build matrix to cover the target technologies and versions you care about. -- By saying "no" you're not getting us anywhere, beyond frustration. |
@bittner I did never intend to imply this particular PR was not going to get merged. To the contrary, all I said was that The test matrix, which is green, covers all puppet versions we're meant to support. The problem is that although the CI does give a sense of when something will definitely break, it will not catch all cases where things might break. Depending on a module that does not support those older puppet versions is something we've been avoiding for a while due to issue we have encountered in the past. The I apologize for the frustration this may have caused the community and you in particular, we absolutely appreciate the contributions from the community and this module has been driven by you guys from day one. |
Sorry if I upset you. But to make things clear: Saying somethings is no good is not the same as a suggestion what to better do instead. I replaced the gem-related library for a reason. You should have read the related issue. And I am not alone with this problem. Please stop making excuses. This only makes things worse. For Datadog. There is clearly passion missing in the maintenance of this module. |
@bittner I'm not sure there is a satisfactory solution for the The solution, I believe goes through releasing a new major version of the module that drops support for older puppets. That said, most of the work here would benefit the current module. Ideally, in that new module scenario integrations should be resources, as opposed to the current approach. But we could maybe leave that for a yet another major release after that one. |
* Bump versions for dependencies Add more versions for supported OSes * Use system_gem instead of puppetserver_gem * Revert "Use system_gem instead of puppetserver_gem" This reverts commit df2cfcd. * [metadata] puppetserver is a _soft_ dependency that would break older puppets - install manually
Can I ask what Datadog's business thinking for supporting unsupported versions of Puppet? Version 6 of the Datadog agent is available as a beta, and our company is looking at trying to use it to test (hopefully with this module). Now seems like it would be a great time to cut some losses on unsupported versions of Puppet and create branch for release 2.x? People can submit fixes to a 1.x branch if they need to pin more gems. The Puppet Enterprise LTS roadmap lists 2016.4 as the minimum. But this module lists requirement for PE 3.2. And Puppet 2.7 when the current release is 5.3
I looked at merging our fork with the current release and the Travis failed because another gem requires Ruby 2.1 - so half the test suite automatically failed. That's going to become a losing maintenance game and certainly not something I would bother fixing. PE 2016.4 runs on Ruby 2.1.9 - that cuts out a good half of the travis.yml lines by itself. You could also entirely remove the module dependency on There would be a few PRs I would submit to fix some problems, but I am really starting to question how useful this module will be if it continues to be pinned to Puppet 2.7 |
@ardrigh Datadog has told me that tomorrow (and every two months) they have community code review at 4pm CET. I'm not sure whether this is a public meeting, though. The meeting location is G+ Hangouts and the #integrations channel of https://datadog.slack.com. @masci Can you tell us more? Maybe this would be a chance to get good input from the community at large? (Unfortunately, I can't join tomorrow due to a client meeting.) |
@ardrigh there are plans in the short-term to drop support for old puppets. What you outline is exactly what we have decided to do. We do have customers on puppet That said, the plan is to release a new Although we might backport features if heavily requested (hoping to phase out I know it's been a little painful, hopefully we can make that a thing of the past very soon. Thank you! |
@ardrigh on another note, regarding beta 6. There was work merged into this module to support agent6 - docs will get updated ahead of the Let me know if you need more information or help getting it to work. |
@truthbk thanks for the replies, that's all very helpful information :) We don't have many changes in our fork at the moment. The previous rpm key changes were integrated into the main release along with the pinned gem fix. I did see the updates for the beta 6 agent added to this module. Is the 1.12 release due soon? |
@ardrigh Can you quote the commit that made this? We're having trouble, it seems, exactly with that addition (see below for the output of an RSpec test we have). That makes it impossible for us to use the current master branch.
|
) * Bump versions for dependencies Add more versions for supported OSes * Use system_gem instead of puppetserver_gem * Revert "Use system_gem instead of puppetserver_gem" This reverts commit df2cfcd. * [metadata] puppetserver is a _soft_ dependency that would break older puppets - install manually
5623b0d
to
df2cfcd
Compare
#387 has been merged and should address most if not all concerns raised in this PR. It will be released soon (like today). Please open any PRs to address any possible bug or limitation against the latest master after the release. Thank you @bittner @ardrigh #387 should allow you to jump on the agent6 bandwagon hopefully without too many issues. Let us know how it goes. As said above, we will be releasing v 2.0 of the module later today. |
@truthbk Thanks for the update. I'll give the new release a spin when it's officially available. |
This PR loosens the dependency on concat and ruby, and replaces puppetserver_gem, trying to address the following issues:
puppetserver_gem
#250 (puppetserver_gem) -- soft dependency mentioned in README