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

Debian Fixes #330

Merged
merged 3 commits into from Mar 25, 2016

Conversation

Projects
None yet
5 participants
@bdwyertech
Contributor

bdwyertech commented Dec 22, 2015

Fixes/Enhancements:

  • use dpkg_autostart to cleanly prevent dpkg from automatically running RabbitMQ after installation
  • Make the Debian installation behave more like RedHat by allowing package upgrades

bdwyertech added some commits Dec 22, 2015

Fixes/Enhancements:
- use `dpkg_autostart` to cleanly prevent dpkg from automatically running RabbitMQ after installation
Fixes/Enhancements:
- Make the Debian installation behave more like RedHat by allowing package upgrades
@jjasghar

This comment has been minimized.

Show comment
Hide comment
@jjasghar

jjasghar Jan 10, 2016

Collaborator

Nice, thanks for this. As soon as we get another 👍 I'll merge this in.

Collaborator

jjasghar commented Jan 10, 2016

Nice, thanks for this. As soon as we get another 👍 I'll merge this in.

@drazzib

This comment has been minimized.

Show comment
Hide comment
@drazzib

drazzib Mar 3, 2016

Just tested this PR, it's okay for me

drazzib commented Mar 3, 2016

Just tested this PR, it's okay for me

@jjasghar jjasghar merged commit a698457 into rabbitmq:master Mar 25, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@iramello

This comment has been minimized.

Show comment
Hide comment
@iramello

iramello Apr 3, 2016

I don't see a reason why this block was changed. We are testing that we are using a Debian-like system, so using dpkg_package resource is the same as above (and specifying provider). Anyways, changing line 63 for :install instead of upgrade, solves issue #356. That's why it used to work.

iramello commented on recipes/default.rb in 4c40ead Apr 3, 2016

I don't see a reason why this block was changed. We are testing that we are using a Debian-like system, so using dpkg_package resource is the same as above (and specifying provider). Anyways, changing line 63 for :install instead of upgrade, solves issue #356. That's why it used to work.

This comment has been minimized.

Show comment
Hide comment
@pianoman19372

pianoman19372 Jun 8, 2016

there appears to be a slight change in the dpkg provider thats provided by chef-client v11 and chef-client v12

in my testing, this code works perfectly with chef-client v12, in chef-client v11 i receive an error

No candidate version available for rabbitmq-server

i see this as a bug in chef-client v11 and not a bug in this recipe

pianoman19372 replied Jun 8, 2016

there appears to be a slight change in the dpkg provider thats provided by chef-client v11 and chef-client v12

in my testing, this code works perfectly with chef-client v12, in chef-client v11 i receive an error

No candidate version available for rabbitmq-server

i see this as a bug in chef-client v11 and not a bug in this recipe

@bdwyertech

This comment has been minimized.

Show comment
Hide comment
@bdwyertech

bdwyertech Apr 4, 2016

Contributor

@iramello It has been a while since I have been hands-on with this cookbook, but if I remember correctly, the reason was that dpkg_package wasn't handling upgrades correctly... Odd, as I believe the package resource just calls the dpkg_package resource behind the scenes anyway. Maybe this behavior has been changed in a newer release of Chef; there have been a few since then.

Did you do a checksum of the downloaded deb file and compare it against the checksum of the version you want? It has been a long while since I've been hands on with this cookbook, but the way things used to be, there were quite a few attributes you have to change/override to get version swaps to work correctly. At one point, I seem to remember it downloading one version and saving it with a file name of the desired version, but the .deb itself was for the version set in this cookbooks default attributes... Had to override a couple things to get it to behave correctly.

Anyway, I'll try to reproduce that bug you are seeing sometime this week and debug if there's an issue.

Contributor

bdwyertech commented Apr 4, 2016

@iramello It has been a while since I have been hands-on with this cookbook, but if I remember correctly, the reason was that dpkg_package wasn't handling upgrades correctly... Odd, as I believe the package resource just calls the dpkg_package resource behind the scenes anyway. Maybe this behavior has been changed in a newer release of Chef; there have been a few since then.

Did you do a checksum of the downloaded deb file and compare it against the checksum of the version you want? It has been a long while since I've been hands on with this cookbook, but the way things used to be, there were quite a few attributes you have to change/override to get version swaps to work correctly. At one point, I seem to remember it downloading one version and saving it with a file name of the desired version, but the .deb itself was for the version set in this cookbooks default attributes... Had to override a couple things to get it to behave correctly.

Anyway, I'll try to reproduce that bug you are seeing sometime this week and debug if there's an issue.

@iramello

This comment has been minimized.

Show comment
Hide comment
@iramello

iramello Apr 4, 2016

@bdwyertech thanks for your reply. Before manually fixing the issue (:install instead of :upgrade as described above), I didn't do a checksum over the file, however I did try installing the file with "dpkg -i " to check it was not corrupted and it worked fine, version was correct.
What you mention is true, package resource calls dpkg_package, and what's even more weird, dpkg_package does not seem to provide :upgrade action (that's what took me to try switching from action).
One note: We are using AWS Opsworks with Chef 11.10, maybe it's related, not sure.

iramello commented Apr 4, 2016

@bdwyertech thanks for your reply. Before manually fixing the issue (:install instead of :upgrade as described above), I didn't do a checksum over the file, however I did try installing the file with "dpkg -i " to check it was not corrupted and it worked fine, version was correct.
What you mention is true, package resource calls dpkg_package, and what's even more weird, dpkg_package does not seem to provide :upgrade action (that's what took me to try switching from action).
One note: We are using AWS Opsworks with Chef 11.10, maybe it's related, not sure.

@jjasghar

This comment has been minimized.

Show comment
Hide comment
@jjasghar

jjasghar Apr 4, 2016

Collaborator

I'm sorry but we haven't written and only support Chef 12. You'll need to fork this cookbook if you want to support chef 11.

Collaborator

jjasghar commented Apr 4, 2016

I'm sorry but we haven't written and only support Chef 12. You'll need to fork this cookbook if you want to support chef 11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment