foodcritic rake task ~ one that works for me

FoodCritic (a lint tool for your OpsCode Chef cookbooks)
$ gem install foodcritic --no-ri --no-rdoc

Rake Task to get the FoodCritic rolling at your cookbooks
(here cookbook reside in dir 'cookbooks' at the root of directory with Rakefile)
the one at wiki doesn't work for me, but this does

_

quick PuppetMaster Service Script for gem installed puppet set-up

On easy rubygem-way `gem install puppet` installation method for Puppet doesn't get you the *nix platforms service script... so here is one allowing you to perform Start||Stop||Restart||Status service task for puppetmaster.

• Save the file below as '/etc/init.d/puppetmaster'
  $ sudo curl -L -o /etc/init.d/puppetmaster https://gist.github.com/raw/2479100/15f79c68be3f6f6bf516adf385aac1f29f802a45/gistfile1.rb
• and turn on its eXecutable bit
  $ sudo chmod +x /etc/init.d/puppetmaster
• Now you can use it as
  $ service puppetmaster status

PuppetMaster Service Script

[Puppet] Exported Resources is a beautiful thing..... thing to use and improvise

Lately, I've been real blunt towards Puppet because of the soup that leaked some specific scenario flaws in very busy times.
So, it's my duty to applause if I like something which is a novel and beautiful concept.

For a well organized auto-magically managed set-up apart from a fine infrastructure and its configuration management mechanism, a very important part is for the monitoring and logging solution to spread across the infrastructure in a similar seamless and scalable fashion.


Puppet enables it very finely with the use of exporting and collecting resources.

Exported Resources are super virtual resources.
Once exported with the storeconfig setting being true, the puppetmaster consumes and keeps these virtual resources out available for all hosts.

Read in detail: http://docs.puppetlabs.com/guides/exported_resources.html

An example from the link above, using a simple File resource

node a {
  @@file { "/tmp/foo":
      content => "fjskfjs\n",
      tag => "foofile",
  }
}
node b {
  File <<| tag == 'foofile' |>>
}

It'll have its flaws (as all softwares do, mine and others)..... just hope they don't interfere in my use-cases.

MCollective can't handle Puppet ~ just like psychotic love stories

Some puppet-izers didn't like what I said in my last post... still a mess is a mess no matter how worth it might be.
Past 2 months, I've been in pain due to the psychotic love story of MCollective and Puppet.

YES, they are very helpful products to automate configuration management and orchestrate metadata-based multicast-ed actions.

YES, they are now under the same organization PuppetLabs which is whole-heartedly working to improve them so they could retain their status in the started-to-glamour-izing DevOps domain. So, both of them will improve a lot.

But, first of all.
If you don't properly test your corporate-aiming projects over Ruby1.9.x; please do post a big notice on your projects page or at least on first page of your amazing Doc.
My story for past few weeks:
I start using a project..... oh it's failing, debug..... oh it's still failing..... debug.
Ahhhhh, ok ask at IRC.
WHAT? I'm using Ruby1.9.x so its possible I might be facing *some* issues.
Is this is a Joke, I'm trying to stabilize an important project over here.
At least be truthful, and don't behave like TV Commercials with small+quick Disclaimers.

And Again.
I'm managing MCollective over all my instances via Puppet. Obviously, because that's what Puppet is for..... managing state of instances.
I've a CI which instigates MCollective to orchestrate different actions over my infrastructure. That's why I took the pain to get the changing-but-not-releasing MCollective over my infrastructure.


Now, this also involves MCollective firing up Puppet in non-daemonizing mode.
This used to raise an Exception in MCollective due to un-handled 'nil' return value failing up my entire build.
I go on IRC, again trying to get a solution..... I get to know that even this has been fixed later in the git-repo since I rpm-ed it last time. But I also get an answer that this wouldn't work as Puppet no-daemon mode has problems. And if I wanna follow this approach, its my decision.
First of all, what the hell should I do when there is just one straight approach left. Except for if I start using something else to manage MCollective.

Though, I took the latest pull..... rpm-ed it and updated all my nodes. And the Puppet non-daemon problem has not yet been raised.
But, what kind of response is it.
If it wasn't for the team decision..... I'd have changed it overnight x(

Puppet ain't sweet anymore & Marionette-Collective hopeful

its a fine piece of utility working mostly fine, but my luck..... mostly end up getting blocked in my tasks by the flaws in library/utility/framework :(

Puppet ain't sweet.

Puppet is one of the most famous automated configuration management, built upon ruby enforcing just it's DSL to be used to use the power underneath.

(new to it, wanna know more http://puppetlabs.com/puppet/how-puppet-works/)

MCollective is a novel concept with good technical design (which can be still matured, though)  for parallel server orchestration with a filter-enabled broadcast of request distribution.

(new to it, get a glimpse at http://puppetlabs.com/mcollective/introduction/)

Why? What happened? Puppet is Good.
Puppet has been there in the wild for a long time (at-least more than 5yrs) now as compared to the closest competitor to it 'Chef'.
Saying it out-loud the feel I'm getting using them lately ~ as if it is acting like an old pop-artist trying to put out a lot at-once to maintain their superiority over upcoming rockstars.
I've used their older service before which wasn't much glossy (at design level) but a lot more stable and composed at implementation..... which is more important from the perspective of a system-maintaining utility.

When you are always in pace of bringing changes and improving upon your current set-up, you don't want to keep on getting blocked by quickly adapted & recently obsoleted features.

Why do you want me to place 'pluginsync = true' on all the boxes to get this new feature working. Why can't enabling it over PuppetMaster should take care of it. In what kind of consistent system does you require custom-resource-type to be not recognizable over all clients. If you don't wanna it get used over any node, you wouldn't use it there. Plain Simple *hit.

You set-up a new puppet-master at Client side and find out your old, working, correct manifest from tested set-up suddenly start failing. Why? Because the freaking parser is broken and not able interpret the symbol notation anymore. Move onto value-convention and it is working.
Ok, you smashed your head and got that working. Now say you have learnt your lesson of not trusting the newer versions and Gemfile-d it for the bundler to handle. Suddenly it starts failing 'cuz you find out the newer version exists no-more. It was yanked off.

Some of there new suggested approaches in custom facter require Facter v 1.7.0; the gem available up their is still v1.6.5. What? Legacy fact distribution is not supported in the new distributions and is obsolete.

There are also several other design-level implementation which I don't agree and sometime don't agree at all. But, not considering them all, there is too much chaos in Puppet right-now.

What do they expect, to keep on pulling the latest build from repository..... building its rpm/gem and then using it. In what freaking world do you expect this from a platform which has been built to sustain a deterministic state of machine.

MCollective is mostly good, a light of hope that Puppet adopted to lit its gloomy days. But to find out its not properly tested over Ruby1.9.x gets me worried.

[OpsCode Chef] when chef's changes can be re-edited but un-available to Search

[DevOps:///OpsCode.Chef]

ate a weird meal last evening, chef was angry I think.....

When I created an AWS instance in same way (by swiss-'knife ec2 server create...' toolset) using same old boot-up script to get that insance auto-configured as chef-client; instance got created and was visible in the instance list  but not available to my recipes trying to search for it using its applied role and other tags.

The same procedure has worked successfully for all previous time, and with no change it suddenly started failing.

I logged-in to the freshly created instance and exec 'chef-client --once' again, it had a successful run but still the recipe failed to grab the node by its role and tags.
So it was a perfectly performing instance according to its run_list, but not available to other features trying to grab its information over Chef Search mechanism.

What could be the problem?

The answer to it is hidden in knowing how Chef Search function.

Chef Search uses Solr Indexing service, which an enterprise-grade OpenSource search server based upon Apache Lucene.


It has a system service 'chef-solr' which  acts as a wrapper around Solr to be run for Chef.
Though, this service was fine as I was able to search all earlier created nodes..... just the new additions were escaping the act.

Now, if Chef-Solr was working fine then we need to look its source for data. Obviously, it was working fine for already indexed data but didn't happen to index anything newly added.

Chef-Solr gets data passed on from the message queue of RabbitMQ, placed before to ease the load of several concurrent requests for Solr.
Chef-Exapander is a system-level service that fetches data from RabbitMQ's queue and formats them before passing on to chef-solr.

This combination of chef-exapnder and chef-solr acts as final feature of Chef Indexer.

So, I looked for chef-expander service.
It was in failing mode, restarted the service and bam!
We are back up and the new aditions are visible in Chef Search.