Fixing docs to remove references to links under terms/

Removed terms/ directory

Signed-off-by: Dharmit Shah <shahdharmit@gmail.com>

docs/articles/baseimages.md

@@ -11,7 +11,7 @@ parent = "smn_images"
 # Create a base image
 
 So you want to create your own [*Base Image*](
-/terms/image/#base-image)? Great!
+/reference/glossary/#base-image)? Great!
 
 The specific process will depend heavily on the Linux distribution you
 want to package. We have some examples below, and you are encouraged to

docs/reference/builder.md

@@ -100,7 +100,7 @@ be UPPERCASE in order to distinguish them from arguments more easily.
 
 Docker runs the instructions in a `Dockerfile` in order. **The
 first instruction must be \`FROM\`** in order to specify the [*Base
-Image*](/terms/image/#base-image) from which you are building.
+Image*](/reference/glossary/#base-image) from which you are building.
 
 Docker will treat lines that *begin* with `#` as a
 comment. A `#` marker anywhere else in the line will
@@ -251,7 +251,7 @@ Or
 
     FROM <image>@<digest>
 
-The `FROM` instruction sets the [*Base Image*](/terms/image/#base-image)
+The `FROM` instruction sets the [*Base Image*](/reference/glossary/#base-image)
 for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as
 its first instruction. The image can be any valid image – it is especially easy
 to start by **pulling an image** from the [*Public Repositories*](

docs/reference/glossary.md

@@ -19,6 +19,10 @@ aufs (advanced multi layered unification filesystem) is a Linux [filesystem](#fi
 Docker supports as a storage backend. It implements the
 [union mount](http://en.wikipedia.org/wiki/Union_mount) for Linux file systems.
 
+## Base image
+
+An image that has no parent is a **base image**.
+
 ## boot2docker
 
 [boot2docker](http://boot2docker.io/) is a lightweight Linux distribution made

docs/reference/run.md

@@ -19,7 +19,7 @@ parent = "mn_reference"
 **Docker runs processes in isolated containers**. When an operator
 executes `docker run`, she starts a process with its own file system,
 its own networking, and its own isolated process tree.  The
-[*Image*](/terms/image/#image) which starts the process may define
+[*Image*](/reference/glossary/#image) which starts the process may define
 defaults related to the binary to run, the networking to expose, and
 more, but `docker run` gives final control to the operator who starts
 the container from the image. That's the main reason

docs/terms/container.md

@@ -1,51 +0,0 @@
-<!--[metadata]>
-+++
-draft = true
-title = "Container"
-description = "Definitions of a container"
-keywords = ["containers, lxc, concepts, explanation, image,  container"]
-[menu.main]
-parent = "mn_reference"
-+++
-<![end-metadata]-->
-
-# Container
-
-## Introduction
-
-![](/terms/images/docker-filesystems-busyboxrw.png)
-
-Once you start a process in Docker from an [*Image*](/terms/image), Docker
-fetches the image and its [*Parent Image*](/terms/image), and repeats the
-process until it reaches the [*Base Image*](/terms/image/#base-image-def). Then
-the [*Union File System*](/terms/layer) adds a read-write layer on top. That
-read-write layer, plus the information about its [*Parent
-Image*](/terms/image)
-and some additional information like its unique id, networking
-configuration, and resource limits is called a **container**.
-
-## Container state
-
-Containers can change, and so they have state. A container may be
-**running** or **exited**.
-
-When a container is running, the idea of a "container" also includes a
-tree of processes running on the CPU, isolated from the other processes
-running on the host.
-
-When the container is exited, the state of the file system and its exit
-value is preserved. You can start, stop, and restart a container. The
-processes restart from scratch (their memory state is **not** preserved
-in a container), but the file system is just as it was when the
-container was stopped.
-
-You can promote a container to an [*Image*](/terms/image) with `docker commit`.
-Once a container is an image, you can use it as a parent for new containers.
-
-## Container IDs
-
-All containers are identified by a 64 hexadecimal digit string
-(internally a 256bit value). To simplify their use, a short ID of the
-first 12 characters can be used on the command line. There is a small
-possibility of short id collisions, so the docker server will always
-return the long ID.

docs/terms/filesystem.md

@@ -1,42 +0,0 @@
-<!--[metadata]>
-+++
-draft = true
-title = "File system"
-description = "How Linux organizes its persistent storage"
-keywords = ["containers, files,  linux"]
-[menu.main]
-parent = "mn_reference"
-+++
-<![end-metadata]-->
-
-# File system
-
-## Introduction
-
-![](/terms/images/docker-filesystems-generic.png)
-
-In order for a Linux system to run, it typically needs two [file
-systems](http://en.wikipedia.org/wiki/Filesystem):
-
-1. boot file system (bootfs)
-2. root file system (rootfs)
-
-The **boot file system** contains the bootloader and the kernel. The
-user never makes any changes to the boot file system. In fact, soon
-after the boot process is complete, the entire kernel is in memory, and
-the boot file system is unmounted to free up the RAM associated with the
-initrd disk image.
-
-The **root file system** includes the typical directory structure we
-associate with Unix-like operating systems:
-`/dev, /proc, /bin, /etc, /lib, /usr,` and `/tmp` plus all the configuration
-files, binaries and libraries required to run user applications (like bash,
-ls, and so forth).
-
-While there can be important kernel differences between different Linux
-distributions, the contents and organization of the root file system are
-usually what make your software packages dependent on one distribution
-versus another. Docker can help solve this problem by running multiple
-distributions at the same time.
-
-![](/terms/images/docker-filesystems-multiroot.png)

docs/terms/image.md

@@ -1,47 +0,0 @@
-<!--[metadata]>
-+++
-draft = true 
-title = "Image"
-description = "Definition of an image"
-keywords = ["containers, lxc, concepts, explanation, image,  container"]
-[menu.main]
-parent = "mn_reference"
-+++
-<![end-metadata]-->
-
-# Image
-
-## Introduction
-
-![](/terms/images/docker-filesystems-debian.png)
-
-In Docker terminology, a read-only [*Layer*](/terms/layer/#layer) is
-called an **image**. An image never changes.
-
-Since Docker uses a [*Union File System*](/terms/layer/#union-file-system), the
-processes think the whole file system is mounted read-write. But all the
-changes go to the top-most writeable layer, and underneath, the original
-file in the read-only image is unchanged. Since images don't change,
-images do not have state.
-
-![](/terms/images/docker-filesystems-debianrw.png)
-
-## Parent image
-
-![](/terms/images/docker-filesystems-multilayer.png)
-
-Each image may depend on one more image which forms the layer beneath
-it. We sometimes say that the lower image is the **parent** of the upper
-image.
-
-## Base image
-
-An image that has no parent is a **base image**.
-
-## Image IDs
-
-All images are identified by a 64 hexadecimal digit string (internally a
-256bit value). To simplify their use, a short ID of the first 12
-characters can be used on the command line. There is a small possibility
-of short id collisions, so the docker server will always return the long
-ID.

docs/terms/layer.md

@@ -1,42 +0,0 @@
-<!--[metadata]>
-+++
-draft = true
-title = "Layers"
-description = "Organizing the Docker Root File System"
-keywords = ["containers, lxc, concepts, explanation, image,  container"]
-[menu.main]
-parent = "mn_use_docker"
-+++
-<![end-metadata]-->
-
-# Layers
-
-## Introduction
-
-In a traditional Linux boot, the kernel first mounts the root [*File
-System*](/terms/filesystem) as read-only, checks its
-integrity, and then switches the whole rootfs volume to read-write mode.
-
-## Layer
-
-When Docker mounts the rootfs, it starts read-only, as in a traditional
-Linux boot, but then, instead of changing the file system to read-write
-mode, it takes advantage of a [union
-mount](http://en.wikipedia.org/wiki/Union_mount) to add a read-write
-file system *over* the read-only file system. In fact there may be
-multiple read-only file systems stacked on top of each other. We think
-of each one of these file systems as a **layer**.
-
-![](/terms/images/docker-filesystems-multilayer.png)
-
-At first, the top read-write layer has nothing in it, but any time a
-process creates a file, this happens in the top layer. And if something
-needs to update an existing file in a lower layer, then the file gets
-copied to the upper layer and changes go into the copy. The version of
-the file on the lower layer cannot be seen by the applications anymore,
-but it is there, unchanged.
-
-## Union File System
-
-We call the union of the read-write layer and all the read-only layers a
-**union file system**.

docs/terms/registry.md

@@ -1,27 +0,0 @@
-<!--[metadata]>
-+++
-draft = true
-title = "Registry"
-description = "Definition of an Registry"
-keywords = ["containers, concepts, explanation, image, repository,  container"]
-[menu.main]
-parent = "mn_reference"
-+++
-<![end-metadata]-->
-
-# Registry
-
-## Introduction
-
-A Registry is a hosted service containing
-[*repositories*](/terms/repository/#repository-def) of
-[*images*](/terms/image/#image-def) which responds to the Registry API.
-
-The default registry can be accessed using a browser at
-[Docker Hub](https://hub.docker.com) or using the
-`docker search` command.
-
-## Further reading
-
-For more information see [*Working with
-Repositories*](/userguide/dockerrepos/#working-with-the-repository)

docs/terms/repository.md

@@ -1,42 +0,0 @@
-<!--[metadata]>
-+++
-draft = true
-title = "Repository"
-description = "Definition of an Repository"
-keywords = ["containers, concepts, explanation, image, repository,  container"]
-[menu.main]
-parent = "identifier"
-+++
-<![end-metadata]-->
-
-# Repository
-
-## Introduction
-
-A repository is a set of images either on your local Docker server, or
-shared, by pushing it to a [*Registry*](/terms/registry/#registry-def)
-server.
-
-Images can be associated with a repository (or multiple) by giving them
-an image name using one of three different commands:
-
-1. At build time (e.g., `docker build -t IMAGENAME`),
-2. When committing a container (e.g.,
-   `docker commit CONTAINERID IMAGENAME`) or
-3. When tagging an image id with an image name (e.g.,
-   `docker tag IMAGEID IMAGENAME`).
-
-A Fully Qualified Image Name (FQIN) can be made up of 3 parts:
-
-`[registry_hostname[:port]/][user_name/](repository_name:version_tag)`
-
-`username` and `registry_hostname` default to an empty string. When
-`registry_hostname` is an empty string, then `docker push` will push to
-`index.docker.io:80`.
-
-If you create a new repository which you want to share, you will need to
-set at least the `user_name`, as the `default` blank `user_name` prefix is
-reserved for [Official Repositories](/docker-hub/official_repos).
-
-For more information see [*Working with
-Repositories*](/userguide/dockerrepos/#working-with-the-repository)