Support Riak 2.0 about puppet-riak HOT 20 CLOSED

Still nothing one year later?

from puppet-riak.

@perbergland-meltwater - We generally don't use Puppet here, and so simply haven't had internal Puppet expertise available to update. (This reminds me - since this is an unofficial community-supported repo, we should move it to basho-labs instead of basho).

However, take a look at @mchesler's commits (on Mar 25, 2014
mchesler/puppet-riak@basho:master...master ) or @fpgeek's riak2 branch https://github.com/fpgeek/puppet-riak/compare/riak2 , to see how they updated it to work with Riak 2.0

from puppet-riak.

They could send a PR?

from puppet-riak.

@danieldreier & @haf as mentioned on #48, this is a major update and - to me - the main goal. Let's use this (overdue) conversation to keep track of progress on 2.x

from puppet-riak.

Requires feedback from #51 before it can progress to Ready state.

from puppet-riak.

I put together an experimental riak 2-only module last night to see what could be done if we only support puppet 3.7 but without a future parser dependency. It installs riak 2 on CentOS 6 and Debian Wheezy and has pretty extensive rspec-puppet test coverage and basic beaker test coverage. I don't intend that as a fork of this project, but part of me wonders whether it might make sense to build a new riak 2 module in parallel to maintaining this one.

I'm hesitant to make sweeping PRs that make breaking changes to this one, because I'm assuming that 100% of the users of this module use it for Riak 1, and nearly 100% of the new users who are looking for a riak module will be looking to use Riak 2.

from puppet-riak.

@danieldreier I'd be glad to cut a version as it stands right now with 1.3.x support and then move forward with the 2.x goal. That's absolutely the intention from a PM POV.

from puppet-riak.

I agree with moving forward with a 2.x only module, but a little concerned about only supporting puppet 3.7+. We are still using 2.7, although we are planning to upgrade soon.

So If I were to contribute, is this danieldreier/riak2 module the one to use now?

I'm a bit new to the Github workflow. Would these be the basic steps to follow?

• Fork danieldreier/riak2
• Hack
• Commit
• Push
• Add an Issue to discuss/approve the change
• Submit a PR

Is that correct?

from puppet-riak.

@Cornellio I'm really only using my danieldreier/riak2 module as a development testbed, to see what I can do without being constrained by riak 1 or older puppet version compatibility, and without having to add tests onto older code; I'm hoping to wholesale forklift that code into this one after meeting feature-parity and incorporating the features that your and other modules have that I lack. For example, I've been realizing that the system settings are less optional than I had thought.

I should really add a CONTRIBUTING.md file documenting this. The workflow I'd suggest is:

• Fork repository
• Create feature branch
• Hack
• Run rspec-puppet tests locally (rake spec)
• Run beaker tests locally (BEAKER_set=debian-76-x64 BEAKER_destroy=onpass BEAKER_provision=yes rake beaker)
• Commit
• Push
• Submit a PR (discussion can happen on the PR, but if there is a related issue link to it from the PR)
• travis-ci will run rspec-puppet tests against a wider range of puppet versions and settings and will post the result on your PR.

Regarding puppet 3.7, puppet 4 is going to be here sooner than people think. I don't have a specific timeline but I think we're looking in the several-months-out timeframe, because there are very usable pre-release versions and the updated language is (basically) feature-complete in puppet 3.7 if you enable future parser. If you're coming from puppet 2.x, you might considering just jumping straight from your current codebase to getting compatible with 3.7 with future parser enabled, because in 4.x that'll be the only option.

Does that make sense?

from puppet-riak.

I think that makes sense. For the rspec and beaker tests, they ca be run in vanilla Debian and CentoOS Vagrant boxes?

On Mar 26, 2015, at 10:04 AM, Daniel Dreier [email protected] wrote:

@Cornellio I'm really only using my danieldreier/riak2 module as a development testbed, to see what I can do without being constrained by riak 1 or older puppet version compatibility, and without having to add tests onto older code; I'm hoping to wholesale forklift that code into this one after meeting feature-parity and incorporating the features that your and other modules have that I lack. For example, I've been realizing that the system settings are less optional than I had thought.
I should really add a CONTRIBUTING.md file documenting this. The workflow I'd suggest is:
Fork repository
Create feature branch
Hack
Run rspec-puppet tests locally (rake spec)
Run beaker tests locally (BEAKER_set=debian-76-x64 BEAKER_destroy=onpass BEAKER_provision=yes rake beaker)
Commit
Push
Submit a PR (discussion can happen on the PR, but if there is a related issue link to it from the PR)
travis-ci will run rspec-puppet tests against a wider range of puppet versions and settings and will post the result on your PR.
Regarding puppet 3.7, puppet 4 is going to be here sooner than people think. I don't have a specific timeline but I think we're looking in the several-months-out timeframe, because there are very usable pre-release versions and the updated language is (basically) feature-complete in puppet 3.7 if you enable future parser. If you're coming from puppet 2.x, you might considering just jumping straight from your current codebase to getting compatible with 3.7 with future parser enabled, because in 4.x that'll be the only option.
Does that make sense?
—
Reply to this email directly or view it on GitHub.

from puppet-riak.

rspec-puppet and beaker tests are actually run on your host machine. Beaker creates its' own vagrant boxes to run tests inside of, and rspec-puppet uses the puppet you have installed on your development environment to build catalogs. rspec-puppet basically compiles the puppet code into a catalog and then inspects the catalog for certain conditions, whereas beaker actually tries to set up a virtual machine and then use serverspec to verify that the VM is running the expected services, has the right ports listening, etc.

One other step I forgot to add was to add test coverage for any new changes. If it's a straight up refactor of existing code, no new tests are needed. If there's new conditional logic being added or new features, the tests should fail without the code changes and pass with. Conditional logic is best tested in rspec-puppet and full-on integration testing is best done in beaker. If you need assistance in figuring out how to get that test coverage I'd be glad to help.

from puppet-riak.

Thank you, that makes sense and gives me a good opportunity to adopt a proper testing framework.

from puppet-riak.

@danieldreier Riak2 initial version looks good.

In trying to setup my environment for beaker-rspec, I already have Vagrant with the vmware fusion provider, but I see most module tests are geared toward virtual box. I'm trying to get the fusion provider working but have no luck so far following this guidance. Not sure if it's worth the effort as virtual box is so much more common in terms of collaboration.

from puppet-riak.

The beaker docs are pretty spotty; I'm sorry you're having a hard time with it. I've never used it with vmware fusion, but my vagrant - vmware fusion experiences have been poor enough that I switched back to virtualbox.

If you're using either my riak2 module or the PR I just made to merge that into this repo, you should be able to:

bundle install
BEAKER_set=centos-66-x64 BEAKER_destroy=onpass BEAKER_provision=yes bundle exec rake beaker

You will probably want to disable the virtualbox vagrant plugin first; I've had nothing but trouble with it. I'd also recommend you use the vagrant-vbguest and vagrant-cachier vagrant plugins.

The beaker tests will be slow (10 minutes?) with virtualbox or vmware because it has to provision and destroy a VM for each test run. I'd suggest running it once at the beginning of the development session to validate that tests pass when you start, and another run right before you make a PR.

When I get it set up myself, I'll add docs to the CONTRIBUTING.md on how to get it set up with GCE or AWS, since that may be a little faster.

from puppet-riak.

Just FYI to this thread that a PR is up for review: #52

from puppet-riak.

@danieldreier Thank you, I switched to virtualbox instead of fusion and beaker runs now. It's an impressive piece of automation.

On your riak2 module the test process runs completely using bundle exec rake beaker, although I am seeing failures in the module itself (both on CentOS and Ubuntu.) I'll explore more for issues on my end.

I'm also able to run a test cycle with beaker-rspec (against puppetlabs-apache module) with
bundle exec rspec spec/acceptance

from puppet-riak.

I'm not sure the issue is necessarily on your end. I encountered issues with it as well. For context,

I've been doing most of my work using the internal puppetlabs VM pooler, which is a godsend -- it keeps a constantly-running pool of about 1000 VMs running that beaker pulls out of the pool, provisions, tests and sends back, which makes beaker tests take about 45 seconds.

For some reason it's been passing on that platform but not in virtualbox. Just a guess but I suspect that there's a timing issue - the pooler hardware is incredibly fast. My hunch is that riak starts a lot faster on the pooler hardware than it does on a local virtualbox system, and in virtualbox it's not ready for tests to run by the time they start, even though I tried to build in a delay for that.

from puppet-riak.

@Cornellio I think I figured out what was breaking tests in virtualbox and fixed it - look at commit danieldreier@045a240 in #52

from puppet-riak.

Yes indeed, it works fine now.

I'm thinking of adding system tuning settings with the kernel params and ulimits. It'll take me some time to get accustomed to rspec though...

from puppet-riak.

#52 was merged, so this is resolved. The module now only supports raik 2.

from puppet-riak.