We want to lower the maximum number of service instances as much as
possible without affecting service reliability so that we can make
stronger statements about what the maximum cost of running a typical
Nomulus environment might be. This first step likely won't affect the
frontend and tools modules in practice because they aren't typically
running even this many instances, but it will clamp down on the
number of backend instances (which should be fine; it just means the
mapreduces will take longer).
Alpha is tuned down the same as sandbox for consistency reasons.
This also standardizes on the B4 size (which has 512 MiB RAM) for
all instances. Most instances were already using this, and the
deviations from it were seemingly at random. Crucially, backend,
which is likely most sensitive to this because it uses the mapreduce
library, is already on the smaller memory size.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154537995
The YAML configuration files are now being built directly into the
JAR, and not stored in the WEB-INF/ directory, so this is unnecessary.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146815937
This implements the basic framework that allows global YAML
configuration, per-environment custom configuration, and unit-
test-specific configuration.
TESTED=I deployed to alpha, ran some EPP commands through the
nomulus tool, and verified no errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422680
These build rules allow Bazel to generate the .ear and .war files which
appcfg.sh (a tool that comes with the App Engine SDK) can then use to
perform a deployment.
Included in this CL are configurations for five separate production
environments: production, sandbox, alpha, crash, and local.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=129163010
