Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Droplet migration between datacenters #50

Open
larinam opened this issue Jul 15, 2013 · 4 comments
Open

Droplet migration between datacenters #50

larinam opened this issue Jul 15, 2013 · 4 comments

Comments

@larinam
Copy link

larinam commented Jul 15, 2013

There is a VM in one DC, e.g. AMS1. I want to migrate it to the NY1.
I want to execute:
tugboat migrate my-droplet --from=2 --to=1
and in a couple of minutes see my droplet active in the desired datacenter.

@pearkes
Copy link
Collaborator

pearkes commented Jul 15, 2013

I ❤️ this idea!

Here's the steps I think we need to do:

  • Power off the droplet (get user confirmation here)
  • Snapshot the droplet
  • "transfer" the snapshot to the region specified
  • Create a new droplet with the same name as the first, using the snapshot we just made

Some hangups:

  • We can get the size from a show droplet of the original droplet and make it the same
  • How do we know what SSH keys (if any) were used? We can't get that info on show droplet, so we'll need to think about how to ask the user about that, perhaps
  • We should warn that they need to manually re-enable backups

Luckily Tugboat internals are well set-up for this. This shouldn't actually require much code to do. The only API endpoint we need that isn't covered is image transfer. That also isn't upstream in the digital_ocean gem, so we'll need to open a pull request there to get it in.

I'm super busy this week, but could probably take a shot at this next week. In the meantime if anyone else wants to start on it then go for it!

@larinam
Copy link
Author

larinam commented Jul 15, 2013

One more additional step I wanted to add, it would be expectable that no signs of additional work done left in the digital ocean so I'd suggest deleting temporary snapshot.

How do we know what SSH keys (if any) were used? We can't get that info on show droplet, so we'll need to think about how to ask the user about that, perhaps

I think it would be appropriate to exactly mention keys that should again appair on the migrated VM via -k or --keys.

tugboat migrate my-droplet --from=2 --to=1 --keys=191919,494949

We should warn that they need to manually re-enable backups

Via info we can see if there were autobackups enabled, so using api /droplets/[droplet_id]/enable_backups autobackups can be reenabled.

@pearkes
Copy link
Collaborator

pearkes commented Jul 15, 2013

Nice, great points, I agree we should just say that you need to be explicit about the keys, and also about cleaning up afterwards and deleting the snapshot.

Backups, yes. I just made #51 as we'll need that for this then.

So, blocking this are:

@mxdpeep
Copy link

mxdpeep commented Mar 29, 2015

the best way is probably now:

  • power off A)
  • snapshot A)
  • power on A)
  • move image to B)
  • start B)
  • rsync data from A) to B)
  • change DNS IP to point to B)
  • rsync data again from A) to B) just to be sure
  • destroy A) / power off A) & make snapshot /* if you want to restart at location A) later again */

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

No branches or pull requests

4 participants