view tests/test-committer.t @ 40022:33eb670e2834

wireprotov2: define semantics for content redirects

When I implemented the clonebundles feature and deployed it on
hg.mozilla.org using Amazon S3 as a content server, server-side CPU
and bandwidth usage dropped off a cliff and a ton of server scaling
headaches went away pretty much the instant clients with support for
clonebundles were rolled out to Firefox CI.

An obvious takeaway from that experience was that offloading server
load to scalable file servers - potentially backed by a CDN - is a
really good idea. Another takeaway was that Mercurial's wire protocol
wasn't in a good position to support data offload generally.

In wire protocol version 1, there isn't a mechanism in the protocol to
say "grab the data from over here instead." For HTTP, we could teach
the client to follow HTTP redirects. Or we could invent a media type
that encoded redirects inline. But for SSH, we were pretty much out of
luck because that protocol wasn't very flexible.

Wire protocol version 2 offers the opportunity to do something better.

The recent generic server-side content caching layer in the wire
protocol version 2 server demonstrated that it is possible to have
drop-in caching of responses to command requests. This by itself
adds tons of value and already makes the built-in server much more
scalable. But I don't want to stop there.

The existing server-side caching implementation has a big weakness:
it requires the server to send data to the client. This means that
the Mercurial server is potentially sending gigabytes of data to
thousands of clients. This is problematic because compared to scaling
static file servers, scaling dynamic servers is *hard*.

A solution to this is to "offload" serving of content to something
that isn't the Mercurial server. By offloading content serving, you
turn the Mercurial server from a centralized monolithic service to
a distributed mostly-indexing service. Assuming high rates of content
offload, this should drastically reduce the total work performed by
the Mercurial server, both in terms of CPU and data transfer. This
will make Mercurial servers vastly easier to scale.

This commit defines the semantics for "content redirects" in wire
protocol version 2. Essentially:

* Servers advertise the set of locations a response could be served
  from.
* When making requests, clients advertise the set of locations they
  are willing to fetch content from.
* Servers can then replace the inline response with one that says
  "get the response from over here instead."

This feature - when fully implemented - will allow extending the
server-side caching layer to facilitate such things as integrating
your server-side cache with a scalable blob store (such as S3 or
a CDN) and offloading most data transfer to that external service.

This feature could also be leveraged for load balancing. e.g.
requests could come into a central server and then get redirected
to an available mirror depending on server availability or locality.
There's tons of potential :)

Differential Revision: https://phab.mercurial-scm.org/D4774

  $ unset HGUSER
  $ EMAIL="My Name <[e-mail]>"
  $ export EMAIL

  $ hg init test
  $ cd test
  $ touch asdf
  $ hg add asdf
  $ hg commit -m commit-1
  $ hg tip
  changeset:   0:53f268a58230
  tag:         tip
  user:        My Name <[e-mail]>
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     commit-1
  

  $ unset EMAIL
  $ echo 1234 > asdf
  $ hg commit -u "[e-mail]" -m commit-1
  $ hg tip
  changeset:   1:3871b2a9e9bf
  tag:         tip
  user:        [e-mail]
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     commit-1
  
  $ echo "[ui]" >> .hg/hgrc
  $ echo "username = foobar <[e-mail]>" >> .hg/hgrc
  $ echo 12 > asdf
  $ hg commit -m commit-1
  $ hg tip
  changeset:   2:8eeac6695c1c
  tag:         tip
  user:        foobar <[e-mail]>
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     commit-1
  
  $ echo 1 > asdf
  $ hg commit -u "[e-mail]" -m commit-1
  $ hg tip
  changeset:   3:957606a725e4
  tag:         tip
  user:        [e-mail]
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     commit-1
  
  $ echo 123 > asdf
  $ echo "[ui]" > .hg/hgrc
  $ echo "username = " >> .hg/hgrc
  $ hg commit -m commit-1
  abort: no username supplied
  (use 'hg config --edit' to set your username)
  [255]

# test alternate config var

  $ echo 1234 > asdf
  $ echo "[ui]" > .hg/hgrc
  $ echo "user = Foo Bar II <[e-mail]>" >> .hg/hgrc
  $ hg commit -m commit-1
  $ hg tip
  changeset:   4:6f24bfb4c617
  tag:         tip
  user:        Foo Bar II <[e-mail]>
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     commit-1
  
# test prompt username

  $ cat > .hg/hgrc <<EOF
  > [ui]
  > askusername = True
  > EOF

  $ echo 12345 > asdf
  $ hg commit --config ui.interactive=False -m ask
  enter a commit username: 
  no username found, using '[^']*' instead (re)
  $ hg rollback -q

  $ hg commit --config ui.interactive=True -m ask <<EOF
  > Asked User <[e-mail]>
  > EOF
  enter a commit username: Asked User <[e-mail]>
  $ hg tip
  changeset:   5:84c91d963b70
  tag:         tip
  user:        Asked User <[e-mail]>
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     ask
  

# test no .hg/hgrc (uses generated non-interactive username)

  $ echo space > asdf
  $ rm .hg/hgrc
  $ hg commit -m commit-1 2>&1
  no username found, using '[^']*' instead (re)

  $ echo space2 > asdf
  $ hg commit -u ' ' -m commit-1
  transaction abort!
  rollback completed
  abort: empty username!
  [255]

# don't add tests here, previous test is unstable

  $ cd ..