All Your Chef Scripts Just Went Pop!
Any tool that's built to work based on existence of these assumptions, is going to be less and less useful as you bring in more and more external entities to the party.
Join the DZone community and get the full member experience.Join For Free
a while back, i wrote a post on this blog about the tools of the new data centre . there, i argued the view that as we outsource more and more of our "data center", we're going to have less and less control over the state of our infrastructure. and so the tools that make assumptions about infrastructure state and move things from a to b are not going to cut it anymore.
understandably, my post was greeted with disdain by chef and puppet masters as something written by an ignorant business manager, who's unlikely to know anything about being a developer, and doesn't know how things work in the "real" world.
here's how we were bitten by this very same problem yesterday:
we use our idempotent configuration management (not chef or puppet but close enough) scripts to install redis on servers for our customers. these scripts have been working for around 3 years on 8 cloud providers but yesterday they stopped working on digitalocean, causing havoc with many of our deployments.
after further investigation, it turned out that digitalocean updated their based images and the new images didn't include an
you might say: aha! you should have done a
mkdir -p /opt
in your scripts. or perhaps used your own verified base images, instead of the latest ones from digitalocean... yes you would be right saying that and we've changed what we had control over to make sure this doesn't happen again.
as much of a fan of defensive programming as i am, i can see (and have seen) enough cases of unknown, unforeseen and unpredictable cases that cause exactly these issues in real world examples. in a business environment with deadlines, you always draw a line were you think it's reasonable enough to assume something from a third party involved. this could be a directory on a disk, or availability of power and network connections. either way, you're assuming state and working on that basis.
as the number of components and third parties involved grows, so do your assumptions and their probability of them being wrong. any tool that's built to work based on existence of these assumptions, is going to be less and less useful as you bring in more and more external entities to the party.
i just wish we could use cloud 66 for everything we do! unfortunately bootstrapping is sometimes not possible when it defies the laws of physics!
Published at DZone with permission of Khash Sajadi, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.