Closed rveznaver closed 9 years ago
This looks good and is probably a much better alternative to both installing a custom built binary and/or compiling from source from within the cookbook as I had brought up as possible features. Makes sense that most places running Mesos in production would choose to pre-build and pre-package (deb/rpm) their custom Mesos builds. Running this through integration tests now. Have you been able to try this out with a custom package repo?
This change fails all centos based integration tests as it looks like 0.22.0 is being installed regardless of what mesos version is set via the cookbook attributes. I'm guessing this is due to changes in the way we search for and install specific mesos versions from the mesosphere RPM repo. These are the failing suites:
Have not been able to test it with a custom repo yet, but I'm pretty sure it will work with our use case (a wrapper cookbook).
The yum_package provider did not handle the version attribute correctly (meaning: at all) before Chef 2.1.0. The kitchen.yml tests are set to "require_chef_omnibus: 12.0.3". I've done a test with the newest chef version and it works. Maybe we should set a newer chef version?
I am testing against chef 12.1.2 and still see the issues.
Hi @rayrod2030, you're right. The yum_package provider does not support passing a ruby block to the version. I have patched and rebased. Should be fine now.
All integration tests passed. Merging!
If someone would like to mirror the mesosphere repository on their own infrastructure, or have their own packages, one should be able to disable the default mesosphere repository.