update manpage list parsing

Author: juanvallejo

docs/man/man1/oadm-diagnostics.1

@@ -38,16 +38,22 @@ you will receive an error if they are not found. For example:
 .nf
 oadm diagnostics \-\-master\-config=/etc/origin/master/master\-config.yaml
 
+If master/node config files are not found and the \-\-host flag is not
+
 .fi
 .RE
-.IP \n+[step]
 
-\item If master/node config files are not found and the \-\-host flag is not
+.PP
 present, host diagnostics are skipped.
-\item If the client has cluster\-admin access, this access enables cluster
+    If the client has cluster\-admin access, this access enables cluster
+
+.PP
 diagnostics to run which regular users cannot.
-\item If a client config file is not found, client and cluster diagnostics
+    If a client config file is not found, client and cluster diagnostics
+
+.PP
 are skipped.
+
 .PP
 Diagnostics may be individually run by passing diagnostic name as arguments.
 The available diagnostic names are:

docs/man/man1/oc-adm-diagnostics.1

@@ -38,16 +38,22 @@ you will receive an error if they are not found. For example:
 .nf
 oc adm diagnostics \-\-master\-config=/etc/origin/master/master\-config.yaml
 
+If master/node config files are not found and the \-\-host flag is not
+
 .fi
 .RE
-.IP \n+[step]
 
-\item If master/node config files are not found and the \-\-host flag is not
+.PP
 present, host diagnostics are skipped.
-\item If the client has cluster\-admin access, this access enables cluster
+    If the client has cluster\-admin access, this access enables cluster
+
+.PP
 diagnostics to run which regular users cannot.
-\item If a client config file is not found, client and cluster diagnostics
+    If a client config file is not found, client and cluster diagnostics
+
+.PP
 are skipped.
+
 .PP
 Diagnostics may be individually run by passing diagnostic name as arguments.
 The available diagnostic names are:

docs/man/man1/oc-deploy.1

@@ -22,15 +22,26 @@ and scaling up new ones. Use 'oc rollback' to rollback to any previous deploymen
 
 .PP
 There are several deployment strategies defined:
-.IP \n+[step]
 
-\item Rolling (default) \- scales up the new deployment in stages, gradually reducing the number
+.PP
+.RS
+
+.nf
+Rolling (default) \- scales up the new deployment in stages, gradually reducing the number
+
+.fi
+.RE
+
+.PP
 of old deployments. If one of the new deployed pods never becomes "ready", the new deployment
-will be rolled back (scaled down to zero). Use when your application can tolerate two versions
-of code running at the same time (many web applications, scalable databases)
-\item Recreate \- scales the old deployment down to zero, then scales the new deployment up to full.
+  will be rolled back (scaled down to zero). Use when your application can tolerate two versions
+  of code running at the same time (many web applications, scalable databases)
+    Recreate \- scales the old deployment down to zero, then scales the new deployment up to full.
+
+.PP
 Use when your application cannot tolerate two versions of code running at the same time
-\item Custom \- run your own deployment process inside a Docker container using your own scripts.
+    Custom \- run your own deployment process inside a Docker container using your own scripts.
+
 .PP
 If a deployment fails, you may opt to retry it (if the error was transient). Some deployments may
 never successfully complete \- in which case you can use the '\-\-latest' flag to force a redeployment.

docs/man/man1/oc-set-volumes.1

@@ -29,19 +29,30 @@ you cannot change a pod's volumes once it has been created.
 
 .PP
 Volume types include:
-.IP \n+[step]
 
-\item emptydir (empty directory) \fIdefault\fP
+.PP
+.RS
+
+.nf
+emptydir (empty directory) *default*
+
 A directory allocated when the pod is created on a local host, is removed when
 the pod is deleted and is not copied across servers
-\item hostdir (host directory)
+hostdir (host directory)
+
 A directory with specific path on any host (requires elevated privileges)
-\item persistentvolumeclaim or pvc (persistent volume claim)
+persistentvolumeclaim or pvc (persistent volume claim)
+
 Link the volume directory in the container to a persistent volume claim you have
 allocated by name \- a persistent volume claim is a request to allocate storage.
 Note that if your claim hasn't been bound, your pods will not start.
-\item secret (mounted secret)
+secret (mounted secret)
+
 Secret volumes mount a named secret to the provided directory.
+
+.fi
+.RE
+
 .PP
 For descriptions on other volume types, see 
 \[la]https://docs.openshift.com\[ra]

docs/man/man1/oc-types.1

@@ -23,129 +23,135 @@ Services, Deployments, and Builds for delivering changes.
 
 .PP
 Concepts:
-.IP \n+[step]
 
-\item 
 .PP
+.RS
+
+.nf
 Containers:
+
 A definition of how to run one or more processes inside of a portable Linux
 environment. Containers are started from an Image and are usually isolated
 from other containers on the same machine.
-\item 
-.PP
+
 Image:
+
 A layered Linux filesystem that contains application code, dependencies,
 and any supporting operating system libraries. An image is identified by
 a name that can be local to the current cluster or point to a remote Docker
 registry (a storage server for images).
-\item 
-.PP
+
 Pods [pod]:
+
 A set of one or more containers that are deployed onto a Node together and
 share a unique IP and Volumes (persistent storage). Pods also define the
 security and runtime policy for each container.
-\item 
-.PP
+
 Labels:
+
 Labels are key value pairs that can be assigned to any resource in the
 system for grouping and selection. Many resources use labels to identify
 sets of other resources.
-\item 
-.PP
+
 Volumes:
+
 Containers are not persistent by default \- on restart their contents are
 cleared. Volumes are mounted filesystems available to Pods and their
 containers which may be backed by a number of host\-local or network
 attached storage endpoints. The simplest volume type is EmptyDir, which
 is a temporary directory on a single machine. Administrators may also
 allow you to request a Persistent Volume that is automatically attached
 to your pods.
-\item 
-.PP
+
 Nodes [node]:
+
 Machines set up in the cluster to run containers. Usually managed
 by administrators and not by end users.
-\item 
-.PP
+
 Services [svc]:
+
 A name representing a set of pods (or external servers) that are
 accessed by other pods. The service gets an IP and a DNS name, and can be
 exposed externally to the cluster via a port or a Route. It's also easy
 to consume services from pods because an environment variable with the
 name <SERVICE>\_HOST is automatically injected into other pods.
-\item 
-.PP
+
 Routes [route]:
+
 A route is an external DNS entry (either a top level domain or a
 dynamically allocated name) that is created to point to a service so that
 it can be accessed outside the cluster. The administrator may configure
 one or more Routers to handle those routes, typically through an Apache
 or HAProxy load balancer / proxy.
-\item 
-.PP
+
 Replication Controllers [rc]:
+
 A replication controller maintains a specific number of pods based on a
 template that match a set of labels. If pods are deleted (because the
 node they run on is taken out of service) the controller creates a new
 copy of that pod. A replication controller is most commonly used to
 represent a single deployment of part of an application based on a
 built image.
-\item 
-.PP
+
 Deployment Configuration [dc]:
+
 Defines the template for a pod and manages deploying new images or
 configuration changes whenever those change. A single deployment
 configuration is usually analogous to a single micro\-service. Can support
 many different deployment patterns, including full restart, customizable
 rolling updates, and fully custom behaviors, as well as pre\- and post\-
 hooks. Each deployment is represented as a replication controller.
-\item 
-.PP
+
 Build Configuration [bc]:
+
 Contains a description of how to build source code and a base image into a
 new image \- the primary method for delivering changes to your application.
 Builds can be source based and use builder images for common languages like
 Java, PHP, Ruby, or Python, or be Docker based and create builds from a
 Dockerfile. Each build configuration has web\-hooks and can be triggered
 automatically by changes to their base images.
-\item 
-.PP
+
 Builds [build]:
+
 Builds create a new image from source code, other images, Dockerfiles, or
 binary input. A build is run inside of a container and has the same
 restrictions normal pods have. A build usually results in an image pushed
 to a Docker registry, but you can also choose to run a post\-build test that
 does not push an image.
-\item 
-.PP
+
 Image Streams and Image Stream Tags [is,istag]:
+
 An image stream groups sets of related images under tags \- analogous to a
 branch in a source code repository. Each image stream may have one or
 more tags (the default tag is called "latest") and those tags may point
 at external Docker registries, at other tags in the same stream, or be
 controlled to directly point at known images. In addition, images can be
 pushed to an image stream tag directly via the integrated Docker
 registry.
-\item 
-.PP
+
 Secrets [secret]:
+
 The secret resource can hold text or binary secrets for delivery into
 your pods. By default, every container is given a single secret which
 contains a token for accessing the API (with limited privileges) at
 /var/run/secrets/kubernetes.io/serviceaccount. You can create new
 secrets and mount them in your own pods, as well as reference secrets
 from builds (for connecting to remote servers) or use them to import
 remote images into an image stream.
-\item 
-.PP
+
 Projects [project]:
+
 All of the above resources (except Nodes) exist inside of a project.
 Projects have a list of members and their roles, like viewer, editor,
 or admin, as well as a set of security controls on the running pods, and
 limits on how many resources the project can use. The names of each
 resource are unique within a project. Developers may request projects
 be created, but administrators control the resources allocated to
 projects.
+
+.fi
+.RE
+
 .PP
 For more, see 
 \[la]https://docs.openshift.com\[ra]

docs/man/man1/openshift-admin-diagnostics.1

@@ -38,16 +38,22 @@ you will receive an error if they are not found. For example:
 .nf
 openshift admin diagnostics \-\-master\-config=/etc/origin/master/master\-config.yaml
 
+If master/node config files are not found and the \-\-host flag is not
+
 .fi
 .RE
-.IP \n+[step]
 
-\item If master/node config files are not found and the \-\-host flag is not
+.PP
 present, host diagnostics are skipped.
-\item If the client has cluster\-admin access, this access enables cluster
+    If the client has cluster\-admin access, this access enables cluster
+
+.PP
 diagnostics to run which regular users cannot.
-\item If a client config file is not found, client and cluster diagnostics
+    If a client config file is not found, client and cluster diagnostics
+
+.PP
 are skipped.
+
 .PP
 Diagnostics may be individually run by passing diagnostic name as arguments.
 The available diagnostic names are:

docs/man/man1/openshift-cli-adm-diagnostics.1

@@ -38,16 +38,22 @@ you will receive an error if they are not found. For example:
 .nf
 openshift cli adm diagnostics \-\-master\-config=/etc/origin/master/master\-config.yaml
 
+If master/node config files are not found and the \-\-host flag is not
+
 .fi
 .RE
-.IP \n+[step]
 
-\item If master/node config files are not found and the \-\-host flag is not
+.PP
 present, host diagnostics are skipped.
-\item If the client has cluster\-admin access, this access enables cluster
+    If the client has cluster\-admin access, this access enables cluster
+
+.PP
 diagnostics to run which regular users cannot.
-\item If a client config file is not found, client and cluster diagnostics
+    If a client config file is not found, client and cluster diagnostics
+
+.PP
 are skipped.
+
 .PP
 Diagnostics may be individually run by passing diagnostic name as arguments.
 The available diagnostic names are:

docs/man/man1/openshift-cli-deploy.1

@@ -22,15 +22,26 @@ and scaling up new ones. Use 'openshift cli rollback' to rollback to any previou
 
 .PP
 There are several deployment strategies defined:
-.IP \n+[step]
 
-\item Rolling (default) \- scales up the new deployment in stages, gradually reducing the number
+.PP
+.RS
+
+.nf
+Rolling (default) \- scales up the new deployment in stages, gradually reducing the number
+
+.fi
+.RE
+
+.PP
 of old deployments. If one of the new deployed pods never becomes "ready", the new deployment
-will be rolled back (scaled down to zero). Use when your application can tolerate two versions
-of code running at the same time (many web applications, scalable databases)
-\item Recreate \- scales the old deployment down to zero, then scales the new deployment up to full.
+  will be rolled back (scaled down to zero). Use when your application can tolerate two versions
+  of code running at the same time (many web applications, scalable databases)
+    Recreate \- scales the old deployment down to zero, then scales the new deployment up to full.
+
+.PP
 Use when your application cannot tolerate two versions of code running at the same time
-\item Custom \- run your own deployment process inside a Docker container using your own scripts.
+    Custom \- run your own deployment process inside a Docker container using your own scripts.
+
 .PP
 If a deployment fails, you may opt to retry it (if the error was transient). Some deployments may
 never successfully complete \- in which case you can use the '\-\-latest' flag to force a redeployment.