From b43c302c46921625e6eb9864fff91b5484771a19 Mon Sep 17 00:00:00 2001 From: Steven Hanna Date: Thu, 20 Apr 2017 18:26:18 -0400 Subject: [PATCH] Spelling mistakes (#2970) * Spelling mistakes * Delete last_page.md --- _includes/why_d4a.md | 2 +- apidocs/cloud-api-source/source/includes/action.md | 2 +- apidocs/cloud-api-source/source/includes/container.md | 2 +- .../source/includes/dockercloud-events.md | 4 ++-- apidocs/cloud-api-source/source/includes/nodecluster.md | 2 +- apidocs/cloud-api-source/source/includes/service.md | 2 +- apidocs/cloud-api-source/source/includes/stack.md | 2 +- components.md | 2 +- datacenter/dtr/2.0/monitor-troubleshoot/troubleshoot.md | 2 +- .../dtr/2.1/guides/monitor-troubleshoot/troubleshoot.md | 2 +- .../dtr/2.2/guides/admin/configure/garbage-collection.md | 2 +- datacenter/dtr/2.2/guides/index.md | 2 +- datacenter/dtr/2.2/guides/release-notes/index.md | 4 ++-- .../dtr/2.2/guides/user/create-and-manage-webhooks.md | 2 +- .../sign-images/manage-trusted-repositories.md | 2 +- .../ucp/1.1/configuration/use-externally-signed-certs.md | 2 +- datacenter/ucp/2.0/guides/configuration/index.md | 2 +- .../2.0/guides/content-trust/continuous-integration.md | 2 +- .../guides/content-trust/manage-trusted-repositories.md | 2 +- datacenter/ucp/2.0/guides/monitor/index.md | 2 +- .../guides/admin/configure/use-trusted-images-for-ci.md | 2 +- .../admin/configure/use-your-own-tls-certificates.md | 2 +- docker-cloud/cloud-swarm/create-cloud-swarm.md | 2 +- docker-cloud/cloud-swarm/link-aws-swarm.md | 4 ++-- docker-for-aws/faqs.md | 2 +- docker-for-aws/upgrade.md | 2 +- docker-for-mac/index.md | 2 +- docker-for-mac/release-notes.md | 4 ++-- docker-for-windows/index.md | 9 ++++----- docker-for-windows/release-notes.md | 4 ++-- docker-for-windows/troubleshoot.md | 2 +- engine/admin/logging/overview.md | 2 +- engine/swarm/join-nodes.md | 8 ++++---- engine/swarm/networking.md | 2 +- engine/swarm/swarm-mode.md | 2 +- engine/userguide/storagedriver/overlayfs-driver.md | 2 +- machine/reference/create.md | 2 +- registry/deploying.md | 2 +- test.md | 2 +- 39 files changed, 50 insertions(+), 51 deletions(-) diff --git a/_includes/why_d4a.md b/_includes/why_d4a.md index 1f1fa4a36b..dfc6bfc3be 100644 --- a/_includes/why_d4a.md +++ b/_includes/why_d4a.md @@ -80,7 +80,7 @@ reduced. Centralized logging is a critical component of many modern infrastructure stacks. To have these logs indexed and searchable proves invaluable for -debugging appliation and system issues as they come up. Out of the box, Docker +debugging application and system issues as they come up. Out of the box, Docker for {{cloudprovider}} forwards logs from containers to a native cloud provider abstraction ({{cloudprovider_log_dest}}). diff --git a/apidocs/cloud-api-source/source/includes/action.md b/apidocs/cloud-api-source/source/includes/action.md index 236a216ab9..fcbae2f329 100644 --- a/apidocs/cloud-api-source/source/includes/action.md +++ b/apidocs/cloud-api-source/source/includes/action.md @@ -26,7 +26,7 @@ An action represents an API call by a user. Details of the API call such as timestamp, origin IP address, and user agent are logged in the action object. -Simple API calls that do not require asynchronous execution will return immediately with the appropiate HTTP error code and an action object will be created either in `Success` or `Failed` states. API calls that do require asynchronous execution will return HTTP code `202 Accepted` immediately and create an action object in `In progress` state, which will change to `Success` or `Failed` state depending on the outcome of the operation being performed. In both cases the response will include a `X-DockerCloud-Action-URI` header with the resource URI of the created action. +Simple API calls that do not require asynchronous execution will return immediately with the appropriate HTTP error code and an action object will be created either in `Success` or `Failed` states. API calls that do require asynchronous execution will return HTTP code `202 Accepted` immediately and create an action object in `In progress` state, which will change to `Success` or `Failed` state depending on the outcome of the operation being performed. In both cases the response will include a `X-DockerCloud-Action-URI` header with the resource URI of the created action. ### Attributes diff --git a/apidocs/cloud-api-source/source/includes/container.md b/apidocs/cloud-api-source/source/includes/container.md index 41be23b5a8..3cbb590357 100644 --- a/apidocs/cloud-api-source/source/includes/container.md +++ b/apidocs/cloud-api-source/source/includes/container.md @@ -709,7 +709,7 @@ uuid | The UUID of the container to redeploy Parameter | Description --------- | ----------- -reuse_volumes | Wheather to reuse container volumes for this redeploy operation or not (default: `true`). +reuse_volumes | Whether to reuse container volumes for this redeploy operation or not (default: `true`). ## Terminate a container diff --git a/apidocs/cloud-api-source/source/includes/dockercloud-events.md b/apidocs/cloud-api-source/source/includes/dockercloud-events.md index c636dd25f3..b611f9e77c 100644 --- a/apidocs/cloud-api-source/source/includes/dockercloud-events.md +++ b/apidocs/cloud-api-source/source/includes/dockercloud-events.md @@ -33,8 +33,8 @@ This is a [namespaced endpoint](#namespaced-endpoints). | Attribute | Description | |:-------------|:---------------------------------------------------------------------------------------------------------------------------------| -| type | Type of object that was created or updated. For possible values, check the [events types](#event-types) table below. | -| action | Type of action that was executed on the object. Posible values: `create`, `update` or `delete` | +| type | Type of object that was created or updated. For possible values, check the [events types](#event-types) table below. | +| action | Type of action that was executed on the object. Possible values: `create`, `update` or `delete` | | parents | List of resource URIs (REST API) of the parents of the object, according to the "Parent-child hierarchy" table below | | resource_uri | Resource URI (REST API) of the object that was created or updated. You can do a `GET` operation on this URL to fetch its details | | state | The current state of the object | diff --git a/apidocs/cloud-api-source/source/includes/nodecluster.md b/apidocs/cloud-api-source/source/includes/nodecluster.md index f5b6b079c2..e3ed9c2308 100644 --- a/apidocs/cloud-api-source/source/includes/nodecluster.md +++ b/apidocs/cloud-api-source/source/includes/nodecluster.md @@ -85,7 +85,7 @@ You can specify the following options when using the Amazon Web Services provide * `vpc`: VPC-related options (optional) * `id`: AWS VPC identifier of the target VPC where the nodes of the cluster will be deployed (required) - * `subnets`: a list of target subnet indentifiers inside selected VPC. If you specify more than one subnet, Docker Cloud will balance among all of them following a high-availability schema (optional) + * `subnets`: a list of target subnet identifiers inside selected VPC. If you specify more than one subnet, Docker Cloud will balance among all of them following a high-availability schema (optional) * `security_groups`: the security group that will be applied to every node of the cluster (optional) * `iam`: IAM-related options (optional) * `instance_profile_name`: name of the instance profile (container for instance an IAM role) to attach to every node of the cluster (required) diff --git a/apidocs/cloud-api-source/source/includes/service.md b/apidocs/cloud-api-source/source/includes/service.md index 8b77b1ec04..bbc2fd9bdf 100644 --- a/apidocs/cloud-api-source/source/includes/service.md +++ b/apidocs/cloud-api-source/source/includes/service.md @@ -881,7 +881,7 @@ uuid | The UUID of the service to redeploy Parameter | Description --------- | ----------- -reuse_volumes | Wheather to reuse container volumes for this redeploy operation or not (default: `true`). +reuse_volumes | Whether to reuse container volumes for this redeploy operation or not (default: `true`). ## Terminate a service diff --git a/apidocs/cloud-api-source/source/includes/stack.md b/apidocs/cloud-api-source/source/includes/stack.md index bf1bbae5a0..07660d3c75 100644 --- a/apidocs/cloud-api-source/source/includes/stack.md +++ b/apidocs/cloud-api-source/source/includes/stack.md @@ -516,7 +516,7 @@ uuid | The UUID of the stack to redeploy Parameter | Description --------- | ----------- -reuse_volumes | Wheather to reuse container volumes for this redeploy operation or not (default: `true`). +reuse_volumes | Whether to reuse container volumes for this redeploy operation or not (default: `true`). ## Terminate a stack diff --git a/components.md b/components.md index d9fe986415..70c78f747c 100644 --- a/components.md +++ b/components.md @@ -1,5 +1,5 @@ --- -description: Componenets page +description: Components page title: Components hide_from_sitemap: true --- diff --git a/datacenter/dtr/2.0/monitor-troubleshoot/troubleshoot.md b/datacenter/dtr/2.0/monitor-troubleshoot/troubleshoot.md index 892088c9db..868de264a0 100644 --- a/datacenter/dtr/2.0/monitor-troubleshoot/troubleshoot.md +++ b/datacenter/dtr/2.0/monitor-troubleshoot/troubleshoot.md @@ -19,7 +19,7 @@ docker run -it --rm --net dtr-ol --name overlay-test2 --entrypoint ping docker/d ``` You can create new overlay network for this test with `docker network create --d overaly network-name`. You can also use any images that contain `sh` and +-d overlay network-name`. You can also use any images that contain `sh` and `ping` for this test. If the second command succeeds, overlay networking is working. diff --git a/datacenter/dtr/2.1/guides/monitor-troubleshoot/troubleshoot.md b/datacenter/dtr/2.1/guides/monitor-troubleshoot/troubleshoot.md index 1b6015331d..6b92d7b6c1 100644 --- a/datacenter/dtr/2.1/guides/monitor-troubleshoot/troubleshoot.md +++ b/datacenter/dtr/2.1/guides/monitor-troubleshoot/troubleshoot.md @@ -13,7 +13,7 @@ docker run -it --rm --net dtr-ol --name overlay-test1 --entrypoint sh docker/dtr docker run -it --rm --net dtr-ol --name overlay-test2 --entrypoint ping docker/dtr -c 3 overlay-test1 ``` -You can create new overlay network for this test with `docker network create -d overaly network-name`. +You can create new overlay network for this test with `docker network create -d overlay network-name`. You can also use any images that contain `sh` and `ping` for this test. If the second command succeeds, overlay networking is working. diff --git a/datacenter/dtr/2.2/guides/admin/configure/garbage-collection.md b/datacenter/dtr/2.2/guides/admin/configure/garbage-collection.md index cdca339834..da4767e30b 100644 --- a/datacenter/dtr/2.2/guides/admin/configure/garbage-collection.md +++ b/datacenter/dtr/2.2/guides/admin/configure/garbage-collection.md @@ -75,7 +75,7 @@ metadata - The "manifest", which is pulled first and lists all layers and the config file for the image. -All of these files are stored in a content-addressible manner. We take the +All of these files are stored in a content-addressable manner. We take the sha256 hash of the file's content and use the hash as the filename. This means that if tag `example.com/user/blog:1.11.0` and `example.com/user/blog:latest` use the same layers we only store them once. diff --git a/datacenter/dtr/2.2/guides/index.md b/datacenter/dtr/2.2/guides/index.md index 018bbef165..b828469f2c 100644 --- a/datacenter/dtr/2.2/guides/index.md +++ b/datacenter/dtr/2.2/guides/index.md @@ -38,7 +38,7 @@ DTR has the ability to [clean up unreferenced manifests and layers](https://docs ## Built-in access control DTR uses the same authentication mechanism as Docker Universal Control Plane. -Users can be managed manually or syched from LDAP or Active Directory. DTR +Users can be managed manually or synched from LDAP or Active Directory. DTR uses [Role Based Access Control](admin/manage-users/index.md) (RBAC) to allow you to implement fine-grained access control policies for who has access to your Docker images. diff --git a/datacenter/dtr/2.2/guides/release-notes/index.md b/datacenter/dtr/2.2/guides/release-notes/index.md index ccf1492919..d36fea7534 100644 --- a/datacenter/dtr/2.2/guides/release-notes/index.md +++ b/datacenter/dtr/2.2/guides/release-notes/index.md @@ -126,7 +126,7 @@ events like image push, repository creation, and others * The install command was improved to avoid deploying DTR to a node where it cannot run due to port collisions * The `docker/dtr install --ucp-node` flag is now mandatory - * The install command no longer allows deploying replicas with duplica ids + * The install command no longer allows deploying replicas with duplicate ids * The upgrade command now validates if all tags were migrated to the latest version before trying to migrate blob links @@ -141,7 +141,7 @@ letters created * The copy to clipboard button on the repository page now works on Firefox * The repository page now renders properly the repository permissions -* You can now delete a users's full name from the UI +* You can now delete a users full name from the UI * Organization administrators can now see the repositories owned by the organization * The garbage collection settings now show the correct cron values * You can now specify DTR to use port 443 when installing DTR diff --git a/datacenter/dtr/2.2/guides/user/create-and-manage-webhooks.md b/datacenter/dtr/2.2/guides/user/create-and-manage-webhooks.md index da9cab69eb..926a46fdbb 100644 --- a/datacenter/dtr/2.2/guides/user/create-and-manage-webhooks.md +++ b/datacenter/dtr/2.2/guides/user/create-and-manage-webhooks.md @@ -308,6 +308,6 @@ To delete a webhook subscription send a `DELETE` request to which you would like to delete. Note that in order to delete a subscription you must be either a system -administrator or an admistrator for the resource which the payload subscribes +administrator or an administrator for the resource which the payload subscribes to. For example, as a normal user you can only delete subscriptions for repositories which you are an admin of. diff --git a/datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md index 8cd1a5fab0..3708d4f656 100644 --- a/datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md +++ b/datacenter/dtr/2.2/guides/user/manage-images/sign-images/manage-trusted-repositories.md @@ -61,7 +61,7 @@ $ notary status // --unstage 0 $ notary status // --reset ``` -When you're ready to publish your chages to the Notary server, run: +When you're ready to publish your changes to the Notary server, run: ```bash $ notary publish // diff --git a/datacenter/ucp/1.1/configuration/use-externally-signed-certs.md b/datacenter/ucp/1.1/configuration/use-externally-signed-certs.md index 134426466f..ecffb576e8 100644 --- a/datacenter/ucp/1.1/configuration/use-externally-signed-certs.md +++ b/datacenter/ucp/1.1/configuration/use-externally-signed-certs.md @@ -1,7 +1,7 @@ --- description: Learn how to configure Docker Universal Control Plane to use your own certificates. -keywords: Universal Control Plane, UCP, certificate, authentiation, tls +keywords: Universal Control Plane, UCP, certificate, authentication, tls redirect_from: - /ucp/configuration/use-externally-signed-certs/ title: Use externally-signed certificates diff --git a/datacenter/ucp/2.0/guides/configuration/index.md b/datacenter/ucp/2.0/guides/configuration/index.md index 3b040f3776..6c9e527e69 100644 --- a/datacenter/ucp/2.0/guides/configuration/index.md +++ b/datacenter/ucp/2.0/guides/configuration/index.md @@ -1,7 +1,7 @@ --- description: Learn how to configure Docker Universal Control Plane to use your own certificates. -keywords: Universal Control Plane, UCP, certificate, authentiation, tls +keywords: Universal Control Plane, UCP, certificate, authentication, tls title: Use externally-signed certificates --- diff --git a/datacenter/ucp/2.0/guides/content-trust/continuous-integration.md b/datacenter/ucp/2.0/guides/content-trust/continuous-integration.md index cdf4f4d816..79347dc30c 100644 --- a/datacenter/ucp/2.0/guides/content-trust/continuous-integration.md +++ b/datacenter/ucp/2.0/guides/content-trust/continuous-integration.md @@ -106,7 +106,7 @@ will still need to provide them for the commands to work correctly. Now that the repository is initialized, we need to create the delegations for Jenkins. Docker Content Trust treats a delegation role called `targets/releases` specially. It considers this delegation to contain the canonical list of published images for the repository. It is therefore -generally desiable to add all users to this delegation with the following command: +generally desirable to add all users to this delegation with the following command: ``` notary delegation add my_repository targets/releases --all-paths /path/to/cert.pem diff --git a/datacenter/ucp/2.0/guides/content-trust/manage-trusted-repositories.md b/datacenter/ucp/2.0/guides/content-trust/manage-trusted-repositories.md index 5db99fd55e..540eaf4611 100644 --- a/datacenter/ucp/2.0/guides/content-trust/manage-trusted-repositories.md +++ b/datacenter/ucp/2.0/guides/content-trust/manage-trusted-repositories.md @@ -33,7 +33,7 @@ $ notary status // --unstage 0 $ notary status // --reset ``` -When you're ready to publish your chages to the Notary server, run: +When you're ready to publish your changes to the Notary server, run: ```bash $ notary publish // diff --git a/datacenter/ucp/2.0/guides/monitor/index.md b/datacenter/ucp/2.0/guides/monitor/index.md index 50bc30edd9..06f3d98d84 100644 --- a/datacenter/ucp/2.0/guides/monitor/index.md +++ b/datacenter/ucp/2.0/guides/monitor/index.md @@ -31,7 +31,7 @@ are deployed on a node, depend on whether the node is a manager or worker. [Learn more about the UCP architecture](../architecture.md) To check the state and logs of other UCP internal components, go to the -**Containers** page, and appply the **System containers** filter. +**Containers** page, and apply the **System containers** filter. This can help validate that all UCP internal components are up and running. ![](../images/monitor-ucp-3.png){: .with-border} diff --git a/datacenter/ucp/2.1/guides/admin/configure/use-trusted-images-for-ci.md b/datacenter/ucp/2.1/guides/admin/configure/use-trusted-images-for-ci.md index cdf4f4d816..79347dc30c 100644 --- a/datacenter/ucp/2.1/guides/admin/configure/use-trusted-images-for-ci.md +++ b/datacenter/ucp/2.1/guides/admin/configure/use-trusted-images-for-ci.md @@ -106,7 +106,7 @@ will still need to provide them for the commands to work correctly. Now that the repository is initialized, we need to create the delegations for Jenkins. Docker Content Trust treats a delegation role called `targets/releases` specially. It considers this delegation to contain the canonical list of published images for the repository. It is therefore -generally desiable to add all users to this delegation with the following command: +generally desirable to add all users to this delegation with the following command: ``` notary delegation add my_repository targets/releases --all-paths /path/to/cert.pem diff --git a/datacenter/ucp/2.1/guides/admin/configure/use-your-own-tls-certificates.md b/datacenter/ucp/2.1/guides/admin/configure/use-your-own-tls-certificates.md index 137c586c67..da383df383 100644 --- a/datacenter/ucp/2.1/guides/admin/configure/use-your-own-tls-certificates.md +++ b/datacenter/ucp/2.1/guides/admin/configure/use-your-own-tls-certificates.md @@ -1,7 +1,7 @@ --- description: Learn how to configure Docker Universal Control Plane to use your own certificates. -keywords: Universal Control Plane, UCP, certificate, authentiation, tls +keywords: Universal Control Plane, UCP, certificate, authentication, tls title: Use your own TLS certificates --- diff --git a/docker-cloud/cloud-swarm/create-cloud-swarm.md b/docker-cloud/cloud-swarm/create-cloud-swarm.md index beff1e4080..384cf4a89d 100644 --- a/docker-cloud/cloud-swarm/create-cloud-swarm.md +++ b/docker-cloud/cloud-swarm/create-cloud-swarm.md @@ -50,7 +50,7 @@ Learn how to [connect to a swarm through Docker Cloud](connect-to-swarm.md). Learn how to [register existing swarms](register-swarms.md). -You can get an overivew of topics on [swarms in Docker Cloud](index.md). +You can get an overview of topics on [swarms in Docker Cloud](index.md). To find out more about Docker swarm in general, see the Docker engine [Swarm Mode overview](/engine/swarm/). diff --git a/docker-cloud/cloud-swarm/link-aws-swarm.md b/docker-cloud/cloud-swarm/link-aws-swarm.md index 9d3224a86e..5475970cbe 100644 --- a/docker-cloud/cloud-swarm/link-aws-swarm.md +++ b/docker-cloud/cloud-swarm/link-aws-swarm.md @@ -65,7 +65,7 @@ If you already have your AWS account connected to Docker Cloud and used the lega 7. In the **Policy Document** section, copy and paste the policy document found in the [Docker for AWS page](/docker-for-aws/iam-permissions/). 8. Click **Create Policy**. 9. Select and copy the **Role ARN** on the role screen. - It should't have changed, but you'll use it to re-link your account. + It shouldn't have changed, but you'll use it to re-link your account. Because you edited the role's permissions, you need to re-link to your account. Back in Docker Cloud, click the account menu and select **Cloud Settings**, and @@ -91,7 +91,7 @@ You're now ready to deploy a swarm! For next steps, see [create a new swarm in Docker Cloud](create-cloud-swarm.md). -You can get an overivew of topics on [swarms in Docker Cloud](index.md). +You can get an overview of topics on [swarms in Docker Cloud](index.md).