Closed Bug 674083 Opened 13 years ago Closed 13 years ago

Invent & implement teleportation

Categories

(mozilla.org Graveyard :: Server Operations: Projects, task)

Product:
mozilla.org Graveyard
Component:
Server Operations: Projects
Platform:
x86_64
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Unfocused, Assigned: fox2mike)

Details

(Keywords: dev-doc-complete, Whiteboard: [2042q3][docs-will-have-been-needed]) 

Traveling to other parts of the world via a flying metal tube with wings is not only inefficient, its also quite a horrible user experience. Not to mention the huge annual costs to Mozilla.

As an alternative, I'd like to have teleportation invented and implemented under an open standard.

Note that we should be careful about liberally accepting input, as this has proven to not work well in the past (http://youtu.be/F7xoyu08xNE).

Bonus points for having a time travel feature, which could be used to help combat the evil that is timezones.
(In reply to comment #0)
> Bonus points for having a time travel feature, which could be used to help
> combat the evil that is timezones.

I believe that this problem is easily solved by keeping the traveller in some kind of buffer for as long as the timezone difference between the two locations. Straightforward if you can afford enough hard disks for the job. I recommend a RAID setup though.
SSDs maybe? This is certainly projects.
Assignee: server-ops → shyam
Component: Server Operations → Server Operations: Projects
Need an ack from mrz and cshields, this is going to take up a lot of time and resources.
(In reply to comment #3)
> Need an ack from mrz and cshields, this is going to take up a lot of time
> and resources.

+1 here, I could make use of this as well..   Just be sure it is implemented with Puppet and that it is fully documented in the wiki so that oncall can properly troubleshoot teleportation outages.
Whiteboard: [2042q2]
This would make new network setups much easier, I think.
Can I get an ETA on this?
(In reply to comment #6)
> Can I get an ETA on this?

Marked the whiteboard, we'll make this a Q2 2042 goal..
Have we thought about the security and safety risks of this?  http://www.youtube.com/watch?v=m6vYKJerstg is a risk I don't want any of our developers to fall victim to.
I don't know about the timezone issue, but I think we'll need a good bit of extra bandwidth to make this happen. The complete humane genome is around 800MB compressed, and this clearly does not contain memories or experiences or even a person's unique physiology.

Given that the data to be transported (one human being) comes from only one source and we only need one full copy at a time, P2P protocols like bittorrent are unlikely to be of significant assistance. Besides, the use of a P2P system could be construed as a security risk anyway.
Severity: normal → enhancement
colo-trip: --- → sjc1
OS: Other → FreeBSD
Hardware: All → ARM
Whiteboard: [2042q2] → [2042q3]
Ravi is on to something with the colo-trip.  Can we use the teleportation to migrate servers out of sjc1 and into another data center?  Or is this for humans only?
Ravi - This should be in SCL3. Also, Linux.
OS: FreeBSD → Linux
Hardware: ARM → x86_64
"...it has never been /successfully/ tested..."
I propose a new protocol, Derivative of Alpha-Fox Teleport (in other words, DAFT) modeled after the existing Alpha-Fox command language for manipulating such things.

per http://www.alpha-fox.com/resources/ats/manual/#s4 -

tp set otherdest|<0/1>	Allows you to set whether you want people to be able to teleport to arbritrary destinations with your teleporter. Defaulted to 0.
tp set offset|<offset>	For transport rings, allows you to set the offset the rings should rez at. Useful for making rings drop from the ceiling.

etc.
Added SCL3 to the list...

I like where you're going with the idea of using teleportation for the server move.
colo-trip: sjc1 → scl3
Please open a separate visual design bug when it comes time for a logo for this project. I'll start in on some sketches in the meantime.

Thanks!
Need to be sure to use a very precise checksum on the data stream. I'd hate to come out the other end with extra parts.
Please ensure Foundation employees have this enabled in their LDAP. Sick of seeing you guys teleport to Vegas all the time.
Pretty sure the Enterprise working group will take care of this. Dr. Emory Erickson would know more.
(In reply to comment #16)
> Need to be sure to use a very precise checksum on the data stream. I'd hate
> to come out the other end with extra parts.

hrmm.. Might be a good idea to use forward error correction in the stream.
(In reply to comment #14)
> I like where you're going with the idea of using teleportation for the
> server move.

Why stop with people and servers?

Once teleportation v2 rolls out through the rapid release cycle, let's add the ability to teleport ethernet packets themselves.  We will save money and get better speeds on our cross-datacenter p2p links.
colo-trip: scl3 → sjc1
OS: Linux → FreeBSD
Hardware: x86_64 → ARM
colo-trip: sjc1 → scl3
OS: FreeBSD → Linux
Hardware: ARM → x86_64
Will this scale?  Do we need to front this with a LB?  Is this on Zeus's road map to support?
(In reply to comment #16)
> Need to be sure to use a very precise checksum on the data stream. I'd hate
> to come out the other end with extra parts.

Extra parts would be cool, like superpowers. I'd be more worried about less parts.
Fewer actual parts would be an issue, but if we could implement an automated weight-loss algorithm, I'd be ok with that. +1
I think this feature should be available on mobile so we can use it anywhere.

Also, I'd really like to see some unittests.
OS: Linux → All
Hardware: x86_64 → Other
Is this going to require any new Just-in-Time compilation infrastructure?
OS: All → Linux
Hardware: Other → x86_64
You're confusing this with TimeTravel :-)
Man, we really could have used this for bug 448604
(In reply to comment #20)
> Why stop with people and servers?
> 
> Once teleportation v2 rolls out through the rapid release cycle, let's add
> the ability to teleport ethernet packets themselves.  We will save money and
> get better speeds on our cross-datacenter p2p links.

Only once you get time travel going. Then you'll be able to capture packets on an incoming server, send it back in time to when you started the packet capture, and replay the packets at the destination.
I, like so many others, face time crunches and I believe that this issue ought to be raised to a blocker. Any update on who is going to ultimately be responsible for implementation here?
(In reply to comment #29)
> Any update on who is going to ultimately be
> responsible for implementation here?

Assuming the inclusion of the proposed time travel feature: before we can assign this bug to someone, we need to extend Bugzilla to support referencing accounts that don't yet exist, or belong to people who might not have been born.

It's very corp-centric to assume that the implementation will be performed by someone contemporary with the current organization.

As always, this comes down to a tools issue.
From a documentation standpoint, I have concerns about the need to invent new grammatical tenses (such as the past future potential predeterminate). We may need to file dependency bugs against the English language.
Keywords: dev-doc-needed
Whiteboard: [2042q3] → [2042q3][docs-will-have-been-needed]
(In reply to comment #31)
> From a documentation standpoint, I have concerns about the need to invent
> new grammatical tenses (such as the past future potential predeterminate).
> We may need to file dependency bugs against the English language.

As described in Dr. Dan Streetmentioner's "Time Traveler's Handbook of 1001 Tense Formations", the major complication with time travel is indeed grammar. Fortunately for us, this book is already written. Or rather, will be, in the future. We'll simply need to pick up a copy after traveling forward to that time. This will be handy for later discussions about the all-hands lunch we will have had at Milliways, the Restaurant at the End of the Universe.
Two objects cannot share the same space, so requesting needs-tree-logging? in the destination zones.
This has been completed successfully. Unfortunately due to the sensitive nature of the construction required, details must remain private. Said details are available on request to those with timesec bugzilla group privileges, otherwise will be made public in 2042q4 once the final implementation is released.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
AGREED!!
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.