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 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.
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.
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.
No comments:
Post a Comment