Please, please, please let me clone a Linode or a Linode's disk from the API. I'm struggling to see any way to launch preconfigured instances for auto-scaling purposes (a la launching AMI instances with EC2) without this feature. It's a big gaping hole in the current Linode API.

_________________
Got Escher? | @artagesw

It's not exactly like EC2, but you can launch a new Linode and have it use a StackScript to build and configure the server for you.

Yes, but that approach takes considerably more time to build the server, and it is also difficult if not impossible to ensure a particular set of packages, etc. Far quicker and more reliable to have a preconfigured node ready to go.

_________________
Got Escher? | @artagesw

That depends. That's how I configure my systems and it usually only takes about 5 minutes from base to updated, configured, and ready.

How do you ensure the new server is in the same state as your existing servers? Running an update could result in a newer/different version of a package being installed.

_________________
Got Escher? | @artagesw

To be honest I've never had to worry about that. Everything I use pretty much stays within the same major version until the next major OS upgrade.

Right. I need to maintain all nodes in an identical state as far as software versions go (even minor versions cannot differ) as this is a production deployment. The only way I know of to achieve that is through cloning. And the only way to automate it would be through the API. Unless I'm overlooking another possibility?

_________________
Got Escher? | @artagesw

Updating all machines at the same time? It's also not terribly difficult to write a script to update the package list and compare the available versions of installed software versus some expected list before continuing with the upgrade.

Cloning machines to ensure they have the same software revisions is overkill. It's like saying cloning fighter pilots is the only way to ensure that all pilots in the air force are short enough to fit in the cockpit. Well, yes, it would ensure that if the template pilot was short enough, but simply checking the height of pilots before assigning them to fighter duty would be rather simpler.

Most package managers will let you specify specific versions of packages to install. However, this will not automatically account for changes in Linode's base image or removal of that version from the distribution's repository, both of which can and do happen in response to security vulnerabilities or other serious bugs.

I usually let "non-critical" stuff float (I don't care which version of htop is installed, for example); I also trust that Ubuntu's updates to critical stuff aren't going to have serious regressions, but I keep an eye on it. I do, however, pin the packages being installed into the Python virtualenvs to a specific version, which only gets changed through the normal testing/deployment process.

(Then again, my use case is one where cloning would NOT work, as I'd have to build, maintain, and test six or seven different base images to cover different server types. Pain in the bum.)

_________________

/* TODO: need to add signature to posts */

Cloning and updating are two completely different operations. Sometimes there are deployment policies around mission critical systems that disallow updating servers. My use case is auto-scaling - the need to bring up additional instances on the fly in a production environment. It would be unacceptable to bring up servers with modified untested software configurations in this scenario. Policy prohibits deploying an untested configuration. And automatically updating all servers at one time is not something you want to do in the context of auto-scaling, where the goal is to get an immediate boost in performance. You'll get quite the opposite if all your servers are suddenly busy updating themselves.

We update our servers' software and configuration during planned maintenance windows when load is minimal - after having first thoroughly tested the changes in a staging environment.

When cloning for scaling, we want to deploy known/tested configurations.

_________________
Got Escher? | @artagesw