TRITON-2304 New image server names (#77)

Reviewed by: Dan McDonald <[email protected]>

Author: bahamat

CONTRIBUTING.md

@@ -6,13 +6,13 @@
 
 <!--
     Copyright 2019 Joyent, Inc.
+    Copyright 2022 MNX Cloud, Inc.
 -->
 
 # Manta Contribution Guidelines
 
 Thanks for using Manta and for considering contributing to it!
 
-
 # Code
 
 All changes to Manta project repositories go through code review via a GitHub
@@ -27,7 +27,7 @@ See the [developer guide](docs/developer-guide) for useful information about
 building and testing the software.
 
 Manta repositories use the same [Joyent Engineering
-Guidelines](https://github.com/joyent/eng/blob/master/docs/index.md) as
+Guidelines](https://github.com/TritonDataCenter/eng/blob/master/docs/index.md) as
 the Triton project.  Notably:
 
 * The #master branch should be first-customer-ship (FCS) quality at all times.
@@ -38,19 +38,18 @@ the Triton project.  Notably:
 Typically each repository has `make check` to lint and check code style.
 Specific code style can vary by repository.
 
-
 ## Issues
 
 There are two separate issue trackers that are relevant for Manta code:
 
-- An internal-to-Joyent JIRA instance.
+* An internal JIRA instance.
 
   A JIRA ticket has an ID like `MANTA-380`, where "MANTA" is the JIRA project
   name. A read-only view of many JIRA tickets is made available at
   <https://smartos.org/bugview/> (e.g.
   <https://smartos.org/bugview/MANTA-380>).
 
-- GitHub issues for the relevant repository.
+* GitHub issues for the relevant repository.
 
 Before Manta was open sourced, Joyent engineering used a private JIRA instance.
 While Joyent continues to use JIRA internally, we also use GitHub issues for

README.md

@@ -6,6 +6,7 @@
 
 <!--
     Copyright 2020 Joyent, Inc.
+    Copyright 2022 MNX Cloud, Inc.
 -->
 
 # Manta: a scalable, distributed object store
@@ -49,11 +50,10 @@ Community discussion about Manta happens in two main places:
 * In the *#manta* IRC channel on the
   [Libera.chat IRC network](https://libera.chat/).
 
-
 ## Dependencies
 
 Manta is composed of a number of services that deploy on top of Joyent's
-[Triton DataCenter](https://github.com/joyent/triton) platform (just "Triton"
+[Triton DataCenter](https://github.com/TritonDataCenter/triton) platform (just "Triton"
 for short), which is also open-source. Triton provides services for operating
 physical servers (compute nodes), deploying services in containers, monitoring
 services, transmitting and visualizing real-time performance data, and a bunch
@@ -63,7 +63,6 @@ service monitoring.
 Triton itself depends on [SmartOS](http://smartos.org).  Manta also directly
 depends on several SmartOS features, notably ZFS.
 
-
 ## Building and Deploying Manta
 
 Manta service images are built and packaged using the same mechanisms as
@@ -76,7 +75,6 @@ in VMware and then follow those instructions to deploy Manta on it.
 If you want to deploy your own builds of Manta components, see "Deploying your
 own Manta Builds" below.
 
-
 ## Repositories
 
 This repository is just a wrapper containing documentation about Manta.  Manta
@@ -85,52 +83,52 @@ some of the more important ones.
 
 A full list of repositories relevant to Manta is maintained in a [repo manifest
 file](./tools/jr-manifest.json) in this repo. To more conveniently list those
-repos, you can use the [`jr` tool](https://github.com/joyent/joyent-repos#jr).
+repos, you can use the [`jr` tool](https://github.com/TritonDataCenter/joyent-repos#jr).
 
 The front door services respond to requests from the internet at large:
 
-* [muppet](https://github.com/joyent/muppet): the haproxy-based "loadbalancer"
+* [muppet](https://github.com/TritonDataCenter/muppet): the haproxy-based "loadbalancer"
   service
-* [muskie](https://github.com/joyent/manta-muskie): the node.js-based "webapi"
+* [muskie](https://github.com/TritonDataCenter/manta-muskie): the node.js-based "webapi"
   service, this is Manta's "Directory API"
-* [buckets-api](https://github.com/joyent/manta-buckets-api): Node.js-based
+* [buckets-api](https://github.com/TritonDataCenter/manta-buckets-api): Node.js-based
   "buckets-api" service, this is Manta's "Buckets API"
 
 The metadata tiers for the Directory and Buckets APIs store the entire object
 namespace (not object data) as well as backend storage system capacity:
 
-* [manatee](https://github.com/joyent/manatee): the "postgres" service, a
+* [manatee](https://github.com/TritonDataCenter/manatee): the "postgres" service, a
   high-availability postgres cluster using synchronous replication and automatic
   fail-over
-* [moray](https://github.com/joyent/moray): Node-based key-value store built on
+* [moray](https://github.com/TritonDataCenter/moray): Node-based key-value store built on
   top of manatee.  Also responsible for monitoring manatee replication topology
   (i.e., which postgres instance is the master).
-* [electric-moray](https://github.com/joyent/electric-moray): Node-based service
+* [electric-moray](https://github.com/TritonDataCenter/electric-moray): Node-based service
   that provides the same interface as Moray, but which directs requests to one
   or more Moray+Manatee *shards* based on hashing the Moray key.
-* [buckets-mdapi](https://github.com/joyent/manta-buckets-mdapi): a Rust-based
+* [buckets-mdapi](https://github.com/TritonDataCenter/manta-buckets-mdapi): a Rust-based
   API for managing all metadata for the Buckets API
-* [buckets-mdplacement](https://github.com/joyent/manta-buckets-mdplacement): a
+* [buckets-mdplacement](https://github.com/TritonDataCenter/manta-buckets-mdplacement): a
   Rust-based API for handling routing of Buckets API objects to appropriate
   nodes in the storage tier.
 
 The storage tier is responsible for actually storing bits on disk:
 
-* [mako](https://github.com/joyent/manta-mako): the "storage" service, a
+* [mako](https://github.com/TritonDataCenter/manta-mako): the "storage" service, a
   nginx-based server that receives PUT/GET requests from the front door services
   to store object data on disk
-* [minnow](https://github.com/joyent/manta-minnow): a Node-based agent that
+* [minnow](https://github.com/TritonDataCenter/manta-minnow): a Node-based agent that
   runs inside storage instances to periodically report storage capacity to the
   metadata tier
 
 There are a number of services not part of the data path that are critical for
 Manta's operation. For example:
 
-* [binder](https://github.com/joyent/binder): hosts both ZooKeeper (used for
+* [binder](https://github.com/TritonDataCenter/binder): hosts both ZooKeeper (used for
   manatee leader election and for group membership) and a Node-based DNS server
   that keeps track of which instances of each service are online at any given
   time
-* [mahi](https://github.com/joyent/mahi): The "authcache" service for handling authn/authz.
+* [mahi](https://github.com/TritonDataCenter/mahi): The "authcache" service for handling authn/authz.
 
 Most of the above components are *services*, of which there may be multiple
 *instances* in a single Manta deployment. Except for the last category of
@@ -141,7 +139,6 @@ For more details on the architecture, including how these pieces actually fit
 together, see the [Architecture](./docs/operator-guide/architecture.md) section
 of the Operator Guide.
 
-
 ## Deploying your own Manta Builds
 
 As described above, as part of the normal Manta deployment process, you start
@@ -157,7 +154,7 @@ do this:
 
 1. Complete the Manta deployment procedure from the operator guide.
 2. Build a zone image for whatever zone you want to replace.  See the
-   instructions for building [Triton](https://github.com/joyent/triton)
+   instructions for building [Triton](https://github.com/TritonDataCenter/triton)
    zone images.  Manta zones work the same way.  The output of this process
    will be a zone **image**, identified by uuid.  The image is comprised of
    two files: an image manifest (a JSON file) and the image file itself
@@ -184,7 +181,7 @@ do this:
 If for some reason you want to avoid deploying the Joyent builds at all, you'll
 have to follow a more manual procedure.  One approach is to update the SAPI
 configuration for whatever service you want (using sdc-sapi -- see
-[SAPI](https://github.com/joyent/sdc-sapi)) *immediately after* running
+[SAPI](https://github.com/TritonDataCenter/sdc-sapi)) *immediately after* running
 manta-init but before deploying anything.  Note that each subsequent
 "manta-init" will clobber this change, though the SAPI configuration is normally
 only used for the initial deployment anyway.  The other option is to apply the
@@ -198,7 +195,6 @@ components above.  The other two kinds of components are the *platform* and
 *agents*.  Both of these procedures are documented in the Operator Guide,
 and they work to deploy custom builds as well as the official Joyent builds.
 
-
 ## Contributing to Manta
 
 To report bugs or request features, you can submit issues to the Manta project
@@ -208,7 +204,6 @@ you should contact Joyent support instead.
 See the [Contribution Guidelines](./CONTRIBUTING.md) for information about
 contributing changes to the project.
 
-
 ## Design principles
 
 Manta assumes several constraints on the data storage problem:

docs/developer-guide/README.md

@@ -67,7 +67,7 @@ works like this:
 1. Build the repository itself.
 2. Build an image (a zone filesystem template and some metadata) from the
    contents of the built repository.
-3. Optionally, publish the image to updates.joyent.com.
+3. Optionally, publish the image to updates.tritondatacenter.com.
 4. Import the image into a Triton instance.
 5. Provision a new zone from the imported image.
 6. During the first boot, the zone executes a one-time setup script.
@@ -81,14 +81,14 @@ There are tools to automate most of this:
   which assembles an image containing the built Manta component.  The image
   represents a template filesystem with which instances of this
   component will be stamped out.  After the image is built, it can be uploaded
-  to updates.joyent.com. Alternatively, the image can be manually imported to
+  to updates.tritondatacenter.com. Alternatively, the image can be manually imported to
   a Triton instance by copying the image manifest and image file
   (a compressed zfs send stream) to the headnode and running
   "sdc-imgadm import".
 * The "manta-init" command takes care of step 4.  You run this as part of any
   deployment.  See the [Manta Operator's Guide](https://joyent.github.io/manta)
   for details.  After the first run, subsequent runs find new images in
-  updates.joyent.com, import them into the current Triton instance, and mark
+  updates.tritondatacenter.com, import them into the current Triton instance, and mark
   them for use by "manta-deploy". Alternatively, if you have images that were
   manually imported using "sdc-imgadm import", then "manta-init" can be run
   with the "-n" flag to use those local images instead.
@@ -98,7 +98,7 @@ There are tools to automate most of this:
   previous steps.
 
 For more information on the zone setup and boot process, see the
-[manta-scripts](https://github.com/joyent/manta-scripts) repo.
+[manta-scripts](https://github.com/TritonDataCenter/manta-scripts) repo.
 
 
 # Testing changes inside an actual Manta deployment
@@ -137,17 +137,17 @@ which is that most components are delivered as zone images and deployed by
 provisioning new zones from these images.  While the deployment tools are
 slightly different than Triton's, the build process is nearly identical.  The
 common instructions for building zone images are part of the [Triton
-documentation](https://github.com/joyent/triton/blob/master/docs/developer-guide/building.md).
+documentation](https://github.com/TritonDataCenter/triton/blob/master/docs/developer-guide/building.md).
 
 ## Building with your changes
 
 Building a repository checked out to a given git branch will include those
 changes in the resulting image.
 
 One exception, is any `agents` (for example
-[`amon`](https://github.com/joyent/sdc-amon),
-[`config-agent`](https://github.com/joyent/sdc-config-agent/),
-[`registrar`](https://github.com/joyent/registrar), (there are others)) that
+[`amon`](https://github.com/TritonDataCenter/sdc-amon),
+[`config-agent`](https://github.com/TritonDataCenter/sdc-config-agent/),
+[`registrar`](https://github.com/TritonDataCenter/registrar), (there are others)) that
 are bundled within the image.
 
 At build-time, the build will attempt to build agents from the same branch
@@ -163,10 +163,10 @@ branch name as the checked-out branch of the component you're building, before
 finally falling back to the `master` branch of that agent repository.
 
 The mechanism used is described in the
-[`Makefile.agent_prebuilt.defs`](https://github.com/joyent/eng/blob/master/tools/mk/Makefile.agent_prebuilt.defs),
-[`Makefile.agent_prebuilt.targ`](https://github.com/joyent/eng/blob/master/tools/mk/Makefile.agent_prebuilt.targ),
+[`Makefile.agent_prebuilt.defs`](https://github.com/TritonDataCenter/eng/blob/master/tools/mk/Makefile.agent_prebuilt.defs),
+[`Makefile.agent_prebuilt.targ`](https://github.com/TritonDataCenter/eng/blob/master/tools/mk/Makefile.agent_prebuilt.targ),
 and
-[`agent-prebuilt.sh`](https://github.com/joyent/eng/blob/master/tools/agent_prebuilt.sh)
+[`agent-prebuilt.sh`](https://github.com/TritonDataCenter/eng/blob/master/tools/agent_prebuilt.sh)
 files, likely appearing as a git submodule beneath `deps/eng` in the
 component repository.
 
@@ -188,9 +188,9 @@ points the repo at your local dependency:
              "dependencies": {
                      "assert-plus": "0.1.1",
                      "bunyan": "0.16.6",
-    -                "checker": "git://github.com/joyent/node-checker#master",
+    -                "checker": "git://github.com/TritonDataCenter/node-checker#master",
     +                "checker": "git://github.com/davepacheco/node-checker#master",
-                     "moray": "git://github.com/joyent/node-moray.git#master",
+                     "moray": "git://github.com/TritonDataCenter/node-moray.git#master",
                      "posix-getopt": "1.0.0",
                      "pg": "0.11.3",
 

docs/mantav2.md

@@ -73,12 +73,12 @@ currently available in a feature branch of their respective git repositories.
 #### Node.js client
 
 The Node.js Manta client is developed in the
-[joyent/node-manta](https://github.com/joyent/node-manta) repository.
+[joyent/node-manta](https://github.com/TritonDataCenter/node-manta) repository.
 
-- mantav1: Currently on the ["master" branch](https://github.com/joyent/node-manta/tree/master/)
+- mantav1: Currently on the ["master" branch](https://github.com/TritonDataCenter/node-manta/tree/master/)
   of joyent/node-manta, and published to npm as
   ["manta"](https://www.npmjs.com/package/manta) -- i.e. `npm install manta`.
-- mantav2: Currently on the ["buckets" branch](https://github.com/joyent/node-manta/tree/buckets/)
+- mantav2: Currently on the ["buckets" branch](https://github.com/TritonDataCenter/node-manta/tree/buckets/)
   of joyent/node-manta. It is not yet published to npm.
 
 *(The intent is to eventually move mantav2 to the "master" branch and publish it
@@ -89,11 +89,11 @@ to publish to npm as "manta".)*
 #### Java client
 
 The Java Manta client is developed in the
-[joyent/java-manta](https://github.com/joyent/java-manta) repository.
+[joyent/java-manta](https://github.com/TritonDataCenter/java-manta) repository.
 
-- mantav1: Currently on the ["master" branch](https://github.com/joyent/java-manta/tree/master/)
+- mantav1: Currently on the ["master" branch](https://github.com/TritonDataCenter/java-manta/tree/master/)
   of joyent/java-manta. Current release versions are 3.x.
-- mantav2: Currently on the ["buckets-m1" branch](https://github.com/joyent/java-manta/tree/buckets-m1/)
+- mantav2: Currently on the ["buckets-m1" branch](https://github.com/TritonDataCenter/java-manta/tree/buckets-m1/)
   of joyent/java-manta.
 
 *(The intent is to eventually move mantav2 to the "master" branch and release it
@@ -104,7 +104,7 @@ continue to release as 3.x versions.)*
 ## Is mantav1 still supported?
 
 Operation of a Mantav1 per the [mantav1 Operator
-Guide](https://github.com/joyent/manta/blob/mantav1/docs/operator-guide.md)
+Guide](https://github.com/TritonDataCenter/manta/blob/mantav1/docs/operator-guide.md)
 remains unchanged, other than that operators should look for images named
 `mantav1-$servicename` rather than `manta-$servicename`. For example:
 

docs/operator-guide/README.md

@@ -1,9 +1,9 @@
 # Manta Operator Guide
 
 *(Note: This is the operator guide for
-[Mantav2](https://github.com/joyent/manta/blob/master/docs/mantav2.md). If you
+[Mantav2](https://github.com/TritonDataCenter/manta/blob/master/docs/mantav2.md). If you
 are operating a mantav1 deployment, please see the [Mantav1 Operator
-Guide](https://github.com/joyent/manta/blob/mantav1/docs/operator-guide.md).)*
+Guide](https://github.com/TritonDataCenter/manta/blob/mantav1/docs/operator-guide.md).)*
 
 This operator guide is divided into sections: