Resizing instances #297

Open
Fodoj opened this Issue Aug 20, 2015 · 4 comments

Projects

None yet

4 participants

@Fodoj
Contributor
Fodoj commented Aug 20, 2015

Let's say I've decided to describe my infrastructure completely using chef-provisioning. I wrote a recipe like this:

1.upto(3) do |i| 
  machine "my-web-app-#{i}" do
    recipe "my-web-app::default"
    machine_options   {
      bootstrap_options: {
        key_name:             "chef-provisioner",
        instance_type:        "m3.medium"
      }
    }
  end
end

Life is good, I have traffic flowing etc. etc.

One year later I get lots of new customers and my requests doubled or more. I have a choice of either increasing amount of instances or to use larger instances. Or I just see that I need more CPU power and I don't really care about RAM, so I decided to switch to c4.xlarge. I got to my recipe and update it:

1.upto(3) do |i| 
  machine "my-web-app-#{i}" do
    recipe "my-web-app::default"
    machine_options   {
      bootstrap_options: {
        key_name:             "chef-provisioner",
        instance_type:        "c4.xlarge"
      }
    }
  end
end

And then I launch this recipe.

Now goes the question: what happens then? Will be my m3.medium instances shut down and replaced one by one with new ones? Will they be instantly destroyed and I will have few minutes of downtime? Or will chef-provisioning just ignore updated instance type? Or will it not and then just override old nodes and I will end up with 3 new nodes and 3 old ec2 instances that I have to remove manually?

@Fodoj
Contributor
Fodoj commented Aug 20, 2015

More broad question: how good is chef-provisioning(-aws) at handling changes in resources? It is pretty clear how it works with normal chef resources (files, templates, directories), but here we are dealing with infrastructure templating and changing it is a bit tricker.

@gmiranda23
Member

@Fodoj You can think of resources for chef-provisioning-aws operating in a CRUD manner for each underlying AWS object being managed. Chef-provisioning-aws CRUD operations against those objects are only valid if AWS supports such an operation against that object as a valid API call. There is no valid API call to resize a running instance.

Instance resizing is deceiving because while it may appear as a single command via the AWS console, there are quite a few steps happening behind the scenes. The instance type must support resizing. If it does, then the instance must be stopped, the instance attributes are then modified, then the instance is restarted.

This might be an enhancement to consider. But I get tripped up on the scope of it. Instead of action :create for the machine resource, it would need to be something like action :modify (see the user resource, for examples). But that would erroneously lead me to think that all of the machine options are being checked and updated if not in the desired state (clearly, that's not true). Perhaps action :resize would more accurately signal to end users the scope of what is being checked.

To implement, there'd be logic needed to check that the object being managed is eligible for resizing. If eligible; stop, adjust, restart. Some usefulness might be found here.

That still seems pretty broad in scope to me. But if someone mocks up what that would look like, I think we'd consider a PR. @tyler-ball @jkeiser @randomcamel, is that all true? Any guidance to add?

@Fodoj
Contributor
Fodoj commented Aug 23, 2015

Okay, I see, so this feature is not implemented :) I guess you could add on a roadmap tasks to add "update" action to all resources, machien_image would be first one. I might be able to help with that too

@randomcamel
Contributor

@gmiranda23 That's my understanding of the situation, yes. If it were implemented conservatively enough, I don't think we'd object on principle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment