Cloud Server Reboots • Hacker News Board

Re: Cloud Server Reboots

#41

Post by mynameisvlad » Sat, Sep 27, 2014, 6:46 PM UTC

csmitheu wrote: post #39

mikegioia wrote: post #25

Earlier quoted context omitted.

You're missing his point, and it's condescending/naive of you to assume that his app hasn't been tested to withstand it with no information to tell you that. My app has been thoroughly tested to withstand reboots; however, I have 22 machines with rackspace and (a) I've never tested all 22 going down at random times, and (b) I STILL want to be awake in case anything happens unexpectedly. The pain here is the timing an…

Well when you contract out your infrastructure that really should be part of your DR plan. Analysing failure conditions is really priority one when you put your stuff on someone else's turf as you have little control over this, despite contracts etc. You did do a DR plan right and did check your contract with RackSpace? I want to be woken up if something doesn't come back, not if it does or even if it has gone into l…

Jesus christ dude, we get it, you're a perfect sysadmin who has clearly covered all possible bases.

But others are not like you. Systems are not always 100% foolproof, people don't have comprehensive DR plans.

Is it that hard for you to understand why someone may want to be up when there is a reboot? Like seriously?

Re: Cloud Server Reboots

#42

Post by oasisbob » Sat, Sep 27, 2014, 6:50 PM UTC

lvh wrote: post #22

notatoad wrote: post #21

Earlier quoted context omitted.

if the "cells" aren't visible in such a way that you can distribute your application across them, it doesn't really matter that they exist.

How so? It seems like a sufficiently smart comp^H^H^H^Hservice could figure out how to distribute machines across them, even if the user doesn't know they exist. Turns out it's a moot point anyway, because cells are client-visible, and have been contributed upstream to OpenStack as a Nova extension.

It's not a moot point. Just because cell info is in Nova doesn't mean it's publicly visible.

The only way we find out about cell locality is when our account rep gives us an updated spreadsheet. We've inquired about this several times.

If you happen to actually use the Rackspace public cloud and know a specific API call we're missing, I'd love to hear it.

Re: Cloud Server Reboots

#43

Post by oasisbob » Sat, Sep 27, 2014, 7:43 PM UTC

lvh wrote: post #15

oasisbob wrote: post #13

I envy the AWS users who enjoyed the rolling reboots (which were AZ aware!) across a small minority of the EC2 fleet. (~10%, yeah?) At some point on Sunday, I'm going to be picking the pieces of our entire stack. Rackspace doesn't even offer anything like availability zones. The last major maintenance they scheduled was over the July 4th weekend -- wasn't happy with that one either.

Re: availability zones; while technically true, I'm not sure that's a fair comparison. Rackspace provides uptime guarantees for the internal network per monthly billing period, and they do actually organize the DC in cells (and yes, they do the roll-outs cell-aware). Those cells are simply not end-user visible (AFAIK).

For this particular maintenance, we're being told that Rackspace will be proceeding with all cells in a region, in parallel. They will not be respecting cell boundaries.