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

[2.4.0] apt-get install -y -q apt-transport-https always executed #491

Closed
olblak opened this issue Jan 25, 2019 · 5 comments · Fixed by #504
Closed

[2.4.0] apt-get install -y -q apt-transport-https always executed #491

olblak opened this issue Jan 25, 2019 · 5 comments · Fixed by #504

Comments

@olblak
Copy link

olblak commented Jan 25, 2019

It seems that this regression was introduced by this commit
I am wondering why it changed from "ensure_packages" to a simple exec command?

@truthbk
Copy link
Member

truthbk commented Jan 29, 2019

Hi @olblak, thank you for taking the time to bring this up. Indeed this change was brought in here: #463. That PR was motivated by this issue: #423.

We were actually aware of this new behavior, and though unhappy with the fact the module is now chatty, we merged it as a temporary workaround until we had a better understanding of how to fix the module in a more idiomatic way while avoiding triggering that nasty dependency cycle. Unfortunately the dependency cycle was not being caused by the module by itself, but rather by a behavior triggered when used in conjunction with other modules (definitely some versions of the logstash module, possibly others).

We are looking into a better workaround, for sure. If you have any suggestions please let us know.

@marcgascon
Copy link

marcgascon commented Feb 11, 2019

Hello, same issue here, we are having a lot of noise on every puppet run because of that.

I reviewed #463 PR and I don't see a clear answer of why ensure_packages was changed by an exec for apt-transport-https package installation. Can we rollback this part to ensure_packages again? Otherwise if you prefer to keep the exec, we should put the unless directive in the resource to validate if it is installed or not.

If you want I can do the change, just let me know...

Thanks in advance 😄

@fr3nd
Copy link
Contributor

fr3nd commented Feb 12, 2019

IMHO #463 should have never been merged... The 'workaround' is terrible: not only is verbose but it's running apt-get install on every puppet run! Please, consider the implications of running this on every instance where the datadog client is installed...

ensure_packages is the right way to do it even if it (in theory) causes issues with some specific module. Actually, even the puppetlabs/apt module is doing it that way: https://github.com/puppetlabs/puppetlabs-apt/blob/3c7229cde3234bef09ada611c98770269ff595a5/manifests/source.pp#L92

Has this issue been reported in any other module? Maybe the issue is not in the datadog module but in the logstash one.

@fr3nd
Copy link
Contributor

fr3nd commented Mar 14, 2019

The package apt-transport-https is already installed by the apt module in case it's required (see https://github.com/puppetlabs/puppetlabs-apt/blob/3c7229cde3234bef09ada611c98770269ff595a5/manifests/source.pp#L92) since release 4.4.0.

The datadog puppet module requires the module apt, so enforcing the installation using the exec or even the ensure_packages function should not be required.

@truthbk
Copy link
Member

truthbk commented Mar 21, 2019

I merged this and reverted the module to the previous - correct - behavior: #506

We will address the problem for customers who might encounter cycle issues, as was the case with the old logstash module in some other way. I apologize for the inconvenience this has caused. The next version released should address this.

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.

4 participants