Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/deployments.html#overview

The internal link of "Declarative definition" is pointintg to

https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/deployments.html#defining-a-deploymentConfig

But it is not correct, so we cannot jump to the "Defining a deploymentConfig" section. Below is correct URL.

https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/deployments.html#defining-a-deploymentconfig

openshift/origin#3034 makes OpenShift default to setting GOMAXPROCS to the number of available CPUs. Admins can tune this by setting the GOMAXPROCS envvar.

need to document/provide sample of how to configure incremental builds for STI strategy.

@soltysh @danmcp fyi.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/openshift_images/postgresql.html#settings
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/openshift_images/mysql.html#environment-variables
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/openshift_images/mongodb.html#usage

MySQL, PostgreSQL

• No tables for Environment variables, Volumes and Settings
• No explanation of Environment variables like:

 The image recognizes following environment variables that you can set during initialization, by passing -e VAR=VALUE to the Docker run command.

MongoDB

• What is "Table 1. Repository Organization" ? It means "Table 1.Environment variables" ?
• "Running images" is correct meaning (?)
• etc...

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#common-cli-operations

In "Table 2. Common CLI Operations", there are two "describe" row.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/generate_cmd.html#repository-url

The above docs says "reference name" as below, can we use SHA1 tag? Please state it.

The URL may include a specific git reference to use by appending a hash with the reference name:


https://github.com/openshift/ruby-hello-world.git#blog_part1

I don't think there are any docs regarding setting up liveness probes / health checks.

Please refer to: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/liveness/README.md

In Host Preparation says:

2. Install the following packages:

# yum install wget git vim-enhanced net-tools bind-utils \
tmux iptables-services bridge-utils

tmux, vim-enhanced and some packages are not mandatory. We should write mandatory packages only

openshift/origin#2480 updates the title bar for the Management Console to now read "OpenShift Web Console". Per openshift/origin#2444 (comment), the docs should also be updated: rename "Management Console" to "web console" to sync up with marketing materials.

In reference to: https://github.com/openshift/openshift-docs/blame/master/architecture/overview.adoc#L17

If Openshift is a monolithically compiled "fork" of Kubernetes where everything runs in a "single" OpenShift process, how is it a "set of microservices"?

Running OpenShift "on top of" Kubernetes has the implication of:

1. start kuberenetes
2. start OpenShift on the same server

Running OpenShift "alongside" Kubernetes has the implication of:

1. Start OpenShift pointed at an existing Kubernetes cluster

I know there are plans for the second scenario in the long-run, but I don't really understand the "set of microservices" part at all.

@ncdc, do we really poll 3rd party repositories today?

https://github.com/openshift/openshift-docs/blame/master/architecture/infrastructure_components/image_registry.adoc#L31

for example, if some nodes are "secure" and other nodes are "insecure", we can currently label the nodes to ensure workload placement, but we should include some docs on, for example, how to block SDN traffic between these nodes but not to master...

Doc: https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/image_writers_guide/guidelines.html#general-docker-guidelines

This is very very tiny thing. But I believe yum clean all doen't need -y(yes) option. Many users will create Dockerfile with reference to this doc, so please make it clear.

_Current_

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

_TOBE_

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all

http://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth-configuration links to the config topic with an outdated link.

Should point to http://docs.openshift.org/latest/dev_guide/master_node_configuration.html

I'll add something to match the "Report a Content Issue or Contribute" links from the DevCenter: https://developers.openshift.com/en/getting-started-overview.html

https://github.com/openshift/openshift-docs/blob/master/_builder_lib/docsitebuilder/helpers.rb#L193

We are missing documentation on hostPort in the deploymentConfig docs. Not sure what other attributes are missing as well but we should cover all of them even if they are seldom used.

The current builder documentation appears to be here instead of included in the openshift-docs repo that is then published to users here.

Also, I wanted to request some clarification on the builder process documentation here as it currently sounds as thought the user code ends up in a builder container with access to the docker socket, however I was explained to on irc that this is not the case and instead the OpenShift docker-builder container has access to the docker socket so that it may spawn the container in which the user code is actually run/built in.

In admin_guide/install/setup.adoc

OpenShift will increase the security constraints on containers in later beta releases.

There are no more beta releases. There should be an explanation or a link to a description of the increased security constraints on containers.

Looks like we may need to revert. The current content doesn't look ready.

Including a link to the contributor guidelines might be better than adding empty pages (if the goal is to restructure the docs, and content isn't ready)

When using requestheader and oauth/openid providers, it is often desired to specify an external logout url to direct users to on logout to destroy their SSO sessions.

This option is located in the master config file:

assetConfig:
  logoutURL: "..."

If specified, the web console will direct the user to the logoutURL on logout.

In sidebar blocks, two en dashes (when followed immediately by a space) turn into an em dash in the final build. I've observed this in local builds, at least. For example:

****
`$ osc exec -p _<pod>_ -- _<command>_`
****

When rendered, -- in the above turns into a  — . This is potentially confusing at a glance, and problematic if trying to copy/paste something.

@CowboysFan PTAL.

http://docs.openshift.org/latest/architecture/core_objects/kubernetes_model.html#service

I've noticed out of date screenshots in the following topics:

http://docs.openshift.org/latest/dev_guide/new_app.html
http://docs.openshift.org/latest/dev_guide/templates.html
http://docs.openshift.org/latest/dev_guide/projects.html

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#project-cli-operations

I know this may not documentation bug, but Long line with inline formats is cut off in the middle...
For example, I cannot see the whole line of
openshift ex new-project test --display-name="OpenShift 3 Sample" --description="This is an example project to demonstrate OpenShift v3" --admin=anypassword:test-admin
in my display with default font size.

But please feel free to close this report, if you don't think it is not a big problem.

As brought up in this PR: https://github.com/openshift/openshift-docs/pull/405/files , a lot of the example files have the parameter apiversion: v1beta3' or something similar. These should probably be updated tov1` when the time comes.

Are there any other example parameters that need to be updated?

Might want to include some of the info from:

https://github.com/GoogleCloudPlatform/kubernetes/blob/0e804b03a433fb56312d9fc7a2eba90310afc41e/docs/resources.md#processor-cycles

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#project-cli-operations

_<project-name> has a underline prefix. Is it necessary or just a typo?

The simplest way to create a new project is: openshift ex new-project _<project-name> --display-name=<display-name> --description=<description> --admin=<admin-username>

I checked command help, but there is no underline.

$ _output/local/go/bin/openshift ex --help |grep new-project
  new-project <project-name>           create a new project

http://docs.openshift.org/latest/architecture/core_objects/kubernetes_model.html#pod

This pod documentation mentions resource limits, but then links to upstream docs.

The pod example JSON doesn't include any resource limits.

http://docs.openshift.org/latest/dev_guide/limits.html

This doc describes limits and provides an example but doesn't indicate where it can be used.

https://github.com/openshift/training/blob/beta4/beta4/hello-pod.json#L24

This example from the beta training shows a limit range being applied to the pod.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/getting_started/setup.html#host-preparation

_CURRENT_

After docker start in No4, docker start No.7 again. And No7 says "Restart" iptables, but the doc has not started iptables...

4. Enable and start the Docker service:

# systemctl enable docker
# systemctl start docker

7. Restart the iptables and docker services:

# systemctl restart iptables
# systemctl restart docker

_TOBE_

4. Enable the Docker service:

# systemctl enable docker

7. Start the iptables and docker services:

# systemctl start iptables docker

openshift/origin#2530 switches to using per-namespace service accounts to run deployment pods.

The openshift-deployer.{crt,key,kubeconfig} files are no longer generated and the master config no longer includes the deployerKubeConfig field. References to those should be removed from the docs at your convenience once the referenced PR merges.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#cli-object-types
(Table 1. Supported Object Types)

I think "buildconfig" is not correct, "buildConfigs" (plural and large"C") is correct. Or we can use both?

https://github.com/openshift/origin/pull/2777/files#diff-381e09db7a55a712234f2c2413f7d987 adds a configurable namespace used to hold infrastructure components. Currently, those consist of the service accounts used to run build controllers, replication controllers, and deployment controllers.

The option appears in the master config file under the policyConfig stanza:

policyConfig:
  bootstrapPolicyFile: ""
  openshiftInfrastructureNamespace: ""
  openshiftSharedResourcesNamespace: ""
...

If unspecified, the default value is "openshift-infra"

Currently, three privileged service accounts are created in the namespace on server start:

• build-controller, granted the system:build-controller role cluster-wide
• deployment-controller, granted the system:deployment-controller role cluster-wide
• replication-controller, granted the system:replication-controller role cluster-wide

These service accounts are used to run the corresponding controllers, and their usernames (e.g. system:serviceaccount:openshift-infra:build-controller) can be referenced in policy and/or security context constraints.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/getting_started/setup.html#host-preparation

The doc says we open following ports, but there are no explanation what these ports are used for.

Add these rules:

 -A INPUT -p tcp -m state --state NEW -m tcp --dport 10250 -j ACCEPT
 -A INPUT -p tcp -m state --state NEW -m tcp --dport 8443:8444 -j ACCEPT
 -A INPUT -p tcp -m state --state NEW -m tcp --dport 7001 -j ACCEPT
 -A INPUT -p tcp -m state --state NEW -m tcp --dport 4001 -j ACCEPT
 -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
 -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/managing_cli_profiles.html

From my browser (Firefox 36.0) I cannot see the "Description" column, although I can see it with this page.
https://github.com/openshift/openshift-docs/blob/master/using_openshift/managing_cli_profiles.adoc

NOTE: If you need screenshot or something, please just let me know.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#cli-object-types

I think we can't understand only this description and Table of the Supported Object Types. Please give us some example usages.

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/openshift_images/postgresql.html#rhel-7-base-image
and
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/openshift_images/postgresql.html#centos-7-base-image

_current_

$ git clone https://github.com/openshift/postgresql.git
$ cd postgresql
$ make build TARGET=rhel7 VERSION=5.5

$ git clone https://github.com/openshift/postgresql.git
$ cd postgresql
$ make build VERSION=5.5

_TOBE_

$ git clone https://github.com/openshift/postgresql.git
$ cd postgresql
$ make build TARGET=rhel7 VERSION=9.2

$ git clone https://github.com/openshift/postgresql.git
$ cd postgresql
$ make build VERSION=9.2

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#deployment-configurations

Sorry if my understanding is wrong, but I think deploymentConfigs and describe is in the wrong order.

_Current_

osc deploymentConfigs describe <deployment config>

_TOBE_

osc describe deploymentConfigs <deployment config>

The following urls should redirect to the welcome page instead of giving 403 errors or hanging:

http://docs.openshift.org/latest
http://docs.openshift.org/latest/
http://docs.openshift.org/latest/welcome

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/getting_started/installation.html#running-in-a-docker-container

_Current_

$ sudo docker run -d --name "openshift-origin" --net=host --privileged \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /tmp/openshift:/tmp/openshift \
openshift/origin start

$ sudo docker exec -it openshift-origin bash

_TOBE_

$ docker run -d --name "openshift-origin" --net=host --privileged \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /tmp/openshift:/tmp/openshift \
openshift/origin start

$ docker exec -it openshift-origin bash

FYI:
Upstream README also isn't using sudo https://github.com/openshift/origin#getting-started

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/openshift_images/mongodb.html#test-framework

I don't think I will be alone. The section of the Test Famework is unclear and need more information if we include it in the doc.

Actually this make test just run this script and I wonder if we can call it Test Flamework.
https://github.com/openshift/mongodb/blob/master/2.4/test/run

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/scheduler.html#sample-policy-configurations

For example:
_TOBE_

{
  "predicates" : [
    {"name" : "RegionZoneAffinity", "argument" : {"serviceAffinity" : {"labels" : ["region", "zone"]}}}
  ],
  "priorities" : [
    {"name" : "RackSpread", "weight" : 1, "argument" : {"serviceAntiAffinity" : {"label" : "rack"}}}
  ]
}

openshift/origin#3173 adds a "routingConfig" stanza to master-config.yaml:

subdomain is the suffix appended to $service.$namespace. to form the default route hostname

routingConfig:
  subdomain: router.default.svc.cluster.local

If omitted, a subdomain of "router.default.svc.cluster.local" is used

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#cli-object-types
(Table 1. Supported Object Types)

It looks like there are Abbreviated Version "dc" and "bc" for deploymentConfigs and buildConfigs. Can you update Table 1. Supported Object Types?

https://github.com/openshift/origin/blob/master/pkg/cmd/util/clientcmd/factory.go#L142-L143

"dc": "deploymentConfigs",
"bc": "buildConfigs",

CLI Overview - where do you get the binaries from? Different platforms (Windows, Fedora, Mac etc)?

Doc:
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/using_openshift/cli.html#cli-object-types
(Table 1. Supported Object Types)

I think "deploymentConfig" is not correct, "deploymentConfigs" (plural) is correct. Or we can use both?

Looking at sections like Architecture Overview, it's very verbose. No graphics to layout the architecture, where you could click on the architecture you want to learn on and get a short/long description.

When upgrading from 0.4.3 to 0.4.4 i noticed that the value of servicesSubnet changed from 172.30.17.0/24 to 172.30.0.0/16. However getting_started/dev_get_started/setup.adoc suggests setting the docker insecure registry to the former value.

openshift/origin#1742 might be related.

As mentioned in #414, trailing commas cause problems. They used to be OK, so there may be some additional spots in the docs to find and update.

To deploy a project on Openshift, it is required to design a YAML or JSON Kubernetes "template" file based on that API - https://godoc.org/github.com/GoogleCloudPlatform/kubernetes/pkg/api

As this is our responsibility to tell to our clients/end users how to create or generate such a file, that could be interesting that we develop a document explaining the different fields/tags, type, default value, if the field is optional or mandatory like a DTD or XSD file does file XML parsing/validation