Update Promote an image using policies and Mirror images to another registry pages with new screenshots and instructions

ee/dtr/user/promotion-policies/internal-promotion.md

@@ -11,7 +11,7 @@ redirect_from:
 Docker Trusted Registry allows you to create image promotion pipelines based on
 policies.
 
-In this example we'll create an image promotion pipeline such that:
+In this example we will create an image promotion pipeline such that:
 
 1. Developers iterate and push their builds to the `dev/website` repository.
 2. When the team creates a stable build, they make sure their image is tagged
@@ -23,31 +23,30 @@ With this promotion policy, the development team doesn't need access to the
 QA repositories, and the QA team doesn't need access to the development
 repositories.
 
-![promotion example](../../images/internal-promotion-1.svg)
+![promotion example](../../images/internal-promotion-1.png)
 
 ## Configure your repository
 
 Once you've [created the repository](../manage-images/index.md), navigate to
-the **DTR web UI**, go to the **repository details** page, and choose
-**Promotions**.
+the repository page on the DTR web interface, and select the
+**Promotions** tab.
 
 ![repository policies](../../images/internal-promotion-2.png){: .with-border}
 
-Click **New promotion policy**, and define the criteria that an image needs
-to meet to be promoted.
+Click **New promotion policy**, and define the image promotion criteria.
 
-DTR allows defining the following criteria:
+DTR allows you to set your promotion policy based on the following image attributes:
 
-| Name            | Description                                        |
-|:----------------|:---------------------------------------------------|
-| Tag name        | If the tag name contains                           |
-| Component name  | If the image has a given component                 |
-| Vulnerabilities | If the image has vulnerabilities                   |
-| License         | If the image uses an intellectual property license |
+| Name            | Description                                        | Example           |
+|:----------------|:---------------------------------------------------| :----------------|
+| Tag name        | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Promote to Target if Tag name ends in `stable`|
+| Component name  | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Promote to Target if Component name starts with `b` |
+| Vulnerabilities | Whether the image has vulnerabilities – critical, major, minor, or all – and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Promote to Target if Critical vulnerabilities = `3` |
+| License         | Whether the image uses an intellectual property license and is one of or not one of your specified words | Promote to Target if License name = `docker` | 
 
 Now you need to choose what happens to an image that meets all the criteria.
 
-Select the **organization** and **repository** where the image is going to be
+Select the target **organization** or **namespace** and **repository** where the image is going to be
 pushed. You can choose to keep the image tag, or transform the tag into
 something more meaningful in the destination repository, by using a tag template.
 
@@ -59,7 +58,12 @@ timestamp of when the image was promoted.
 ![repository with policies](../../images/internal-promotion-3.png){: .with-border}
 
 Everything is set up! Once the development team pushes an image that complies
-with the policy, it automatically gets promoted.
+with the policy, it automatically gets promoted. To confirm, select the **Promotions** tab on the `dev/website` repository.
+
+![tag promoted](../../images/internal-promotion-5.png){: .with-border}
+
+
+You can also review the newly pushed tag in the target repository by navigating to `qa/website` and selecting the **Tags** tab.
 
 ![tag promoted](../../images/internal-promotion-4.png){: .with-border}
 

ee/dtr/user/promotion-policies/push-mirror.md

@@ -6,46 +6,42 @@ keywords: registry, promotion, mirror
 
 Docker Trusted Registry allows you to create mirroring policies for a repository.
 When an image gets pushed to a repository and meets a certain criteria,
-DTR automatically pushes it to repository in another DTR deployment or Docker
-Hub.
+DTR automatically pushes it to a repository in a remote Docker Trusted or Hub registry.
 
 This not only allows you to mirror images but also allows you to create
 image promotion pipelines that span multiple DTR deployments and datacenters.
 
-In this example we'll create an image mirroring policy such that:
+In this example we will create an image mirroring policy such that:
 
-1. Developers iterate and push their builds to `dev.example.org/website/ui`, the
-`website/ui` repository in the DTR deployment dedicated to development.
+1. Developers iterate and push their builds to `dtr-example.com/dev/website` &endash; the
+repository in the DTR deployment dedicated to development.
 2. When the team creates a stable build, they make sure their image is tagged
 with `-stable`.
-3. When a stable build is pushed to `dev.example.org/website/ui`, it will
-automatically be pushed to `qa.example.org/website/ui`, mirroring the image and
+3. When a stable build is pushed to `dtr-example.com/dev/website`, it will
+automatically be pushed to `qa-example.com/qa/website`, mirroring the image and
 promoting it to the next stage of development.
 
-![promotion example](../../images/push-mirror-1.svg)
-
-With this mirroring policy, the development team doesn't need access to the
-QA cluster, and the QA team doesn't need access to the development
+With this mirroring policy, the development team does not need access to the
+QA cluster, and the QA team does not need access to the development
 cluster.
 
-The person setting this mirroring policy needs to have permissions to push
-to the destination repository.
+You need to have permissions to push to the destination repository in order to set up the mirroring policy.
 
 ## Configure your repository
 
-Once you've [created the repository](../manage-images/index.md), navigate to
-the **DTR web UI**, go to the **repository details** page, and choose
-**Mirrors**.
+Once you have [created the repository](../manage-images/index.md), navigate to
+the repository page on the web interface, and select the
+**Mirrors** tab.
 
 ![create integration](../../images/push-mirror-2.png){: .with-border}
 
-Click **New mirroring policy**, and define where the image will be pushed if
-it meets the policy criteria. Make sure the account you use for the integration
-has permissions to write in the destination repository.
+Click **New mirror**, and define where the image will be pushed if
+it meets the mirroring criteria. Make sure the account you use for the integration
+has permissions to write to the remote repository. Under **Mirror direction**, choose **Push to remote registry**. 
 
-In this example we'll push the image to the `website/ui` repository of a
-DTR deployment available at `qa.example.org`. We also use a service account
-that was created just for mirroring images between repositories.
+In this example, the image gets pushed to the `qa/website` repository of a
+DTR deployment available at `qa-example.com` using a service account
+that was created just for mirroring images between repositories. Note that you may use a password or access token to log in to your remote registry.
 
 If the destination DTR deployment is using self-signed TLS certificates or
 certificates issued by your own certificate authority, click
@@ -58,33 +54,28 @@ Once you're done, click **Connect** to test the integration.
 
 ![test connection](../../images/push-mirror-3.png){: .with-border}
 
-Under **Mirror direction** choose **push to remote registry**. Then specify the
-policy that will trigger the image to be pushed to the external registry.
+DTR allows you to set your mirroring policy based on the following image attributes:
 
-DTR allows defining the following criteria:
-
-| Name            | Description                                        |
-|:----------------|:---------------------------------------------------|
-| Tag name        | If the tag name contains                           |
-| Component name  | If the image has a given component                 |
-| Vulnerabilities | If the image has vulnerabilities                   |
-| License         | If the image uses an intellectual property license |
+| Name            | Description                                        | Example           |
+|:----------------|:---------------------------------------------------| :----------------|
+| Tag name        | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Copy image to remote repository if Tag name ends in `stable`|
+| Component name  | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Copy image to remote repository if Component name starts with `b` |
+| Vulnerabilities | Whether the image has vulnerabilities – critical, major, minor, or all – and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Copy image to remote repository if Critical vulnerabilities = `3` |
+| License         | Whether the image uses an intellectual property license and is one of or not one of your specified words | Copy image to remote repository if License name = `docker` | 
 
 Finally you can choose to keep the image tag, or transform the tag into
-something more meaningful in the destination registry, by using a tag template.
+something more meaningful in the remote registry by using a tag template.
 
 ![choose policy](../../images/push-mirror-4.png){: .with-border}
 
-In this example, if an image in the `website/ui` repository is tagged with
+In this example, if an image in the `dev/website` repository is tagged with
 a word that ends in "stable", DTR will automatically push that image to
-the DTR deployment available at `qa.example.org`. The image is pushed to the
-`website/ui` repository and is tagged with the timestamp of when the image
+the DTR deployment available at `qa-example.com`. The image is pushed to the
+`qa/website` repository and is tagged with the timestamp of when the image
 was promoted.
 
 Everything is set up! Once the development team pushes an image that complies
-with the policy, it automatically gets promoted.
-
-![choose policy](../../images/push-mirror-5.png){: .with-border}
+with the policy, it automatically gets promoted to `qa/website` in the remote trusted registry at `qa-example.com`.
 
 ## Metadata persistence