Rename 'registry_tool' to 'nomulus'

This changes everything with external visibility beyond the codebase
(i.e. the name of the compiled binary and the documentation that refers
to it). It does not change a lot of things internal to the codebase,
i.e. the "RegistryTool" class didn't change its name. We can rename that
in a subsequent CL if we want to.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135022087

docs/admin-tool.md

@@ -1,32 +1,32 @@
-# Registry tool
+# Admin tool
 
-The registry tool is a command-line registry administration tool that is invoked
-using the `registry_tool` command. It has the ability to view and change a large
+Nomulus includes a command-line registry administration tool that is invoked
+using the `nomulus` command. It has the ability to view and change a large
 number of things in a running domain registry environment, including creating
 registrars, updating premium and reserved lists, running an EPP command from a
 given XML file, and performing various backend tasks like re-running RDE if the
 most recent export failed. Its code lives inside the tools package
-(`java/google/registry/tools`), and is compiled by building the `registry_tool`
+(`java/google/registry/tools`), and is compiled by building the `nomulus`
 target in the Bazel BUILD file in that package.
 
 To build the tool and display its command-line help, execute this command:
 
-    $ bazel run //java/google/registry/tool:registry_tool -- --help
+    $ bazel run //java/google/registry/tools:nomulus -- --help
 
 For future invocations you should alias the compiled binary in the
 `bazel-genfiles/java/google/registry` directory or add it to your path so that
 you can run it more easily. The rest of this guide assumes that it has been
-aliased to `registry_tool`.
+aliased to `nomulus`.
 
 The registry tool is always called with a specific environment to run in using
 the -e parameter. This looks like:
 
-    $ registry_tool -e production {command name} {command parameters}
+    $ nomulus -e production {command name} {command parameters}
 
 To see a list of all available commands along with usage information, run
-registry_tool without specifying a command name, e.g.:
+nomulus without specifying a command name, e.g.:
 
-    $ registry_tool -e alpha
+    $ nomulus -e alpha
 
 Note that the documentation for the commands comes from JCommander, which parses
 metadata contained within the code to yield documentation.

docs/app-engine-architecture.md

@@ -59,7 +59,7 @@ contact/host deletion).
 
 ### Tools service
 
-The tools service is responsible for servicing requests from the `registry_tool`
+The tools service is responsible for servicing requests from the `nomulus`
 command line tool, which provides administrative-level functionality for
 developers and tech support employees of the registry. It is thus the least
 critical of the three services. Requests to the tools service are handled by the

docs/code-structure.md

@@ -21,7 +21,7 @@ time.
 
 Cursors are rolled forward at the end of successful tasks, are not rolled
 forward in the case of failure, and can be manually set backwards using the
-update_cursors command in registry_tool to reprocess a past action.
+`nomulus update_cursors` command to reprocess a past action.
 
 The following cursor types are defined:
 

docs/configuration.md

@@ -5,7 +5,7 @@ working registry system up and running. Broadly speaking, configuration works in
 two ways -- globally, for the entire sytem, and per-TLD. Global configuration is
 managed by editing code and deploying a new version, whereas per-TLD
 configuration is data that lives in Datastore in `Registry` entities, and is
-updated by running `registry_tool` commands without having to deploy a new
+updated by running `nomulus` commands without having to deploy a new
 version.
 
 ## Environments
@@ -113,9 +113,9 @@ configuration. They contain any kind of configuration that is specific to a TLD,
 such as the create/renew price of a domain name, the pricing engine
 implementation, the DNS writer implementation, whether escrow exports are
 enabled, the default currency, the reserved label lists, and more. The
-`update_tld` command in `registry_tool` is used to set all of these options. See
-the "Registry tool" documentation for more information, as well as the
-command-line help for the `update_tld` command. Unlike global configuration
+`nomulus update_tld` command is used to set all of these options. See
+the [admin tool documentation](./admin-tool.md) for more information, as well as
+the command-line help for the `update_tld` command. Unlike global configuration
 above, per-TLD configuration options are stored as data in the running system,
 and thus do not require code pushes to update.
 

docs/install.md

@@ -81,7 +81,7 @@ Then to fire up an instance of the server, run:
 
     $ bazel run //javatests/google/registry/server {your params}
 
-Once it is running, you can interact with it via normal `registry_tool`
+Once it is running, you can interact with it via normal `nomulus`
 commands, or view the registrar console in a web browser by navigating to
 http://localhost:8080/registrar .
 
@@ -130,8 +130,8 @@ Then, use `appcfg` to [deploy the WAR files]
 Once the code is deployed, the next step is to play around with creating some
 entities in the registry, including a TLD, a registrar, a domain, a contact, and
 a host. Note: Do this on a non-production environment! All commands below use
-`registry_tool` to interact with the running registry system; see the
-documentation on `registry_tool` for additional information on it. We'll assume
+`nomulus` to interact with the running registry system; see the
+documentation on `nomulus` for additional information on it. We'll assume
 that all commands below are running in the `alpha` environment; if you named
 your environment differently, then use that everywhere that `alpha` appears.
 
@@ -141,7 +141,7 @@ Pick the name of a TLD to create. For the purposes of this example we'll use
 "example", which conveniently happens to be an ICANN reserved string, meaning
 it'll never be created for real on the Internet at large.
 
-    $ registry_tool -e alpha create_tld example --roid_suffix EXAMPLE \
+    $ nomulus -e alpha create_tld example --roid_suffix EXAMPLE \
       --initial_tld_state GENERAL_AVAILABILITY --tld_type TEST
     [ ... snip confirmation prompt ... ]
     Perform this command? (y/N): y
@@ -167,7 +167,7 @@ id of a domain resource is a hex string followed by the suffix, e.g.
 Now we need to create a registrar and give it access to operate on the example
 TLD. For the purposes of our example we'll name the registrar "Acme".
 
-    $ registry_tool -e alpha create_registrar acme --name 'ACME Corp' \
+    $ nomulus -e alpha create_registrar acme --name 'ACME Corp' \
       --registrar_type TEST --password hunter2 \
       --icann_referral_email blaine@acme.example --street '123 Fake St' \
       --city 'Fakington' --state MA --zip 12345 --cc US --allowed_tlds example
@@ -194,14 +194,14 @@ Now we want to create a contact, as a contact is required before a domain can be
 created. Contacts can be used on any number of domains across any number of
 TLDs, and contain the information on who owns or provides technical support for
 a TLD. These details will appear in WHOIS queries. Note the `-c` parameter,
-which stands for client identifier: This is used on most `registry_tool`
+which stands for client identifier: This is used on most `nomulus`
 commands, and is used to specify the id of the registrar that the command will
 be executed using. Contact, domain, and host creation all work by constructing
 an EPP message that is sent to the registry, and EPP commands need to run under
 the context of a registrar. The "acme" registrar that was created above is used
 for this purpose.
 
-    $ registry_tool -e alpha create_contact -c acme --id abcd1234 \
+    $ nomulus -e alpha create_contact -c acme --id abcd1234 \
       --name 'John Smith' --street '234 Fake St' --city 'North Fakington' \
       --state MA --zip 23456 --cc US --email jsmith@e.mail
     [ ... snip EPP response ... ]
@@ -220,7 +220,7 @@ additionally be subordinate (a subdomain of a domain name that is on this
 registry). Let's create an out-of-bailiwick nameserver, which is the simplest
 type.
 
-    $ my_registry_tool -e alpha create_host -c acme --host ns1.google.com
+    $ nomulus -e alpha create_host -c acme --host ns1.google.com
     [ ... snip EPP response ... ]
 
 Note that hosts are required to have IP addresses if they are subordinate, and
@@ -233,7 +233,7 @@ of IP addresses in either IPv4 or IPv6 format.
 To tie it all together, let's create a domain name that uses the above contact
 and host.
 
-    $ registry_tool -e alpha create_domain -c acme --domain fake.example \
+    $ nomulus -e alpha create_domain -c acme --domain fake.example \
       --admin abcd1234 --tech abcd1234 --registrant abcd1234 \
       --nameservers ns1.google.com
     [ ... snip EPP response ... ]
@@ -244,7 +244,7 @@ technical, and registrant contact. This is quite common on domain names.
 To verify that everything worked, let's query the WHOIS information for
 fake.example:
 
-    $ registry_tool -e alpha whois_query fake.example
+    $ nomulus -e alpha whois_query fake.example
     [ ... snip WHOIS response ... ]
 
 You should see all of the information in WHOIS that you entered above for the

docs/operational-procedures.md

@@ -14,7 +14,7 @@ production registry system.
 The default domain registry codebase comes with a
 `StaticPremiumListPricingEngine` that determines premium prices of domain labels
 (i.e. the part of the domain name without the TLD) by checking for their
-presence on a list of prices in Datastore. `registry_tool` is used to load and
+presence on a list of prices in Datastore. `nomulus` is used to load and
 update these lists from flat text files. The format of this list is simple: It
 is a newline-delimited CSV text file with each line containing the label and its
 price (including currency specifier in ISO-4217 format). As an example:
@@ -45,8 +45,7 @@ Once the file containing the premium prices is ready, run the
 `create_premium_list` command to load it into Datastore as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} create_premium_list -n exampletld \
-    -i exampletld.txt
+$ nomulus -e {ENVIRONMENT} create_premium_list -n exampletld -i exampletld.txt
 
 You are about to save the premium list exampletld with 2 items:
 Perform this command? (y/N): y
@@ -65,8 +64,7 @@ from a text file, the procedure is exactly the same, except using the
 `update_premium_list` command as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} update_premium_list -n exampletld \
-    -i exampletld.txt
+$ nomulus -e {ENVIRONMENT} update_premium_list -n exampletld -i exampletld.txt
 
 You are about to save the premium list exampletld with 2 items:
 Perform this command? (y/N): y
@@ -84,7 +82,7 @@ apply a premium list to a TLD, run the `update_tld` command with the following
 parameter:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} update_tld exampletld --premium_list exampletld
+$ nomulus -e {ENVIRONMENT} update_tld exampletld --premium_list exampletld
 Update Registry@exampletld
 premiumList -> [null, Key<?>(EntityGroupRoot("cross-tld")/PremiumList("exampletld"))]
 
@@ -98,7 +96,7 @@ The `get_tld` command shows which premium list is applied to a TLD (along with
 all other information about a TLD). It is used as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} get_tld exampletld
+$ nomulus -e {ENVIRONMENT} get_tld exampletld
 [ ... snip ... ]
 premiumList=Key<?>(EntityGroupRoot("cross-tld")/PremiumList("exampletld"))
 [ ... snip ... ]
@@ -110,7 +108,7 @@ The `list_premium_lists` command is used to list all premium lists in Datastore.
 It takes no arguments and displays a simple list of premium lists as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} list_premium_lists
+$ nomulus -e {ENVIRONMENT} list_premium_lists
 exampletld
 someotherlist
 ```
@@ -181,7 +179,7 @@ purposes of this example, we are creating a common reserved list named
 "common_bad-words".
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} create_reserved_list -n common_bad-words \
+$ nomulus -e {ENVIRONMENT} create_reserved_list -n common_bad-words \
     -i common_bad-words.txt
 [ ... snip long confirmation prompt ... ]
 Perform this command? (y/N): y
@@ -200,7 +198,7 @@ file containing the reserved list entries, then pass it as input to the
 `update_reserved_list` command as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} update_reserved_list -n common_bad-words \
+$ nomulus -e {ENVIRONMENT} update_reserved_list -n common_bad-words \
     -i common_bad-words.txt
 [ ... snip diff of changes to list entries ... ]
 Perform this command? (y/N): y
@@ -223,7 +221,7 @@ To add a reserved list to a TLD, run the `update_tld` command with the following
 parameter:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} update_tld exampletld \
+$ nomulus -e {ENVIRONMENT} update_tld exampletld \
     --add_reserved_lists common_bad-words
 Update Registry@exampletld
 reservedLists -> [null, [Key<?>(EntityGroupRoot("cross-tld")/ReservedList("common_bad-words"))]]
@@ -247,7 +245,7 @@ along with lots of other information about that TLD which is not relevant to our
 purposes here. It is used as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} get_tld exampletld
+$ nomulus -e {ENVIRONMENT} get_tld exampletld
 [ ... snip ... ]
 reservedLists=[Key<?>(EntityGroupRoot("cross-tld")/ReservedList("common_bad-words"))]
 [ ... snip ... ]
@@ -260,7 +258,7 @@ Datastore. It takes no arguments and displays a simple list of reserved lists in
 newline-delimited format as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} list_reserved_lists
+$ nomulus -e {ENVIRONMENT} list_reserved_lists
 common_bad-words
 exampletld_some-other-list
 ```
@@ -282,7 +280,7 @@ acceptable solution is to simply skip the bad data.
 Cursors can be updated as follows:
 
 ```shell
-$ registry_tool -e {ENVIRONMENT} update_cursors exampletld --type RDE_STAGING \
+$ nomulus -e {ENVIRONMENT} update_cursors exampletld --type RDE_STAGING \
     --timestamp 2016-09-01T00:00:00Z
 Update Cursor@ahFzfmRvbWFpbi1yZWdpc3RyeXIzCxIPRW50aXR5R3JvdXBSb290Igljcm9zcy10bGQMCxIIUmVnaXN0cnkiB3lvdXR1YmUM_RDE_STAGING
 cursorTime -> [2016-09-23T00:00:00.000Z, 2016-09-01T00:00:00.000Z]