Conditionalizing problem links for Dedicated build

architecture/additional_concepts/authentication.adoc

@@ -14,10 +14,12 @@ The authentication layer identifies the user associated with requests to the
 OpenShift API. The authorization layer then uses information about the
 requesting user to determine if the request should be allowed.
 
+ifdef::openshift-enterprise,openshift-origin[]
 As an administrator, you can
 link:../../install_config/configuring_authentication.html[configure authentication]
 using a link:../../install_config/master_node_configuration.html[master
 configuration file].
+endif::[]
 
 [[users-and-groups]]
 
@@ -29,17 +31,26 @@ interacting with OpenShift.
 
 A user can be assigned to one or more _groups_, each of which represent a
 certain set of users. Groups are useful when
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html[managing authorization
-policies] to grant permissions to multiple users at once, for example allowing
+policies]
+endif::[]
+ifdef::openshift-dedicated[]
+managing authorization policies
+endif::[]
+to grant permissions to multiple users at once, for example allowing
 access to link:../core_concepts/index.html[objects] within a
 link:../core_concepts/projects_and_users.html#projects[project], versus granting
 them to users individually.
 
 In addition to explicitly defined groups, there are also
 system groups, or _virtual groups_, that are automatically provisioned by
-OpenShift. These can be seen when
+OpenShift.
+ifdef::openshift-enterprise,openshift-origin[]
+These can be seen when
 link:../../admin_guide/manage_authorization_policy.html#viewing-cluster-bindings[viewing
 cluster bindings].
+endif::[]
 
 In the default set of virtual groups, note the following in
 particular:
@@ -83,8 +94,14 @@ The OpenShift master includes a built-in OAuth server. Users obtain OAuth
 access tokens to authenticate themselves to the API.
 
 When a person requests a new OAuth token, the OAuth server uses the configured
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../install_config/configuring_authentication.html[identity
-provider] to determine the identity of the person making the request.
+provider]
+endif::[]
+ifdef::openshift-dedicated[]
+identity provider
+endif::[]
+to determine the identity of the person making the request.
 
 It then determines what user that identity maps to, creates an access token for
 that user, and returns the token for use.
@@ -139,8 +156,13 @@ $ oc create -f <(echo '
 All requests for OAuth tokens involve a request to `_<master>_/oauth/authorize`.
 Most authentication integrations place an authenticating proxy in front of this
 endpoint, or configure OpenShift to validate credentials against a backing
-link:../../install_config/configuring_authentication.html[identity provider].
-
+ifdef::openshift-enterprise,openshift-origin[]
+link:../../install_config/configuring_authentication.html[identity
+provider].
+endif::[]
+ifdef::openshift-dedicated[]
+identity provider.
+endif::[]
 Requests to `_<master>_/oauth/authorize` can come from user-agents that cannot
 display interactive login pages, such as the CLI. Therefore, OpenShift supports
 authenticating using a `WWW-Authenticate` challenge in addition to interactive
@@ -158,11 +180,9 @@ should only be sent if a `X-CSRF-Token` header is present on the request. Client
 to receive Basic `WWW-Authenticate` challenges should set this header to a non-empty value.
 
 If the authenticating proxy cannot support `WWW-Authenticate` challenges, or if
-OpenShift is configured to use an
-link:../../install_config/configuring_authentication.html[identity provider] that
-does not support WWW-Authenticate challenges, users can visit
-`_<master>_/oauth/token/request` using a browser to obtain an access token
-manually.
+OpenShift is configured to use an identity provider that does not support
+WWW-Authenticate challenges, users can visit `_<master>_/oauth/token/request`
+using a browser to obtain an access token manually.
 ====
 
 *Obtaining OAuth Tokens* [[obtaining-oauth-tokens]]

architecture/additional_concepts/authorization.adoc

@@ -39,12 +39,16 @@ link:#roles[role].
 
 |===
 
-Rules, roles, and bindings can be visualized
+Cluster administrators can visualize rules, roles, and bindings
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#viewing-roles-and-bindings[using
-the CLI]. For example, consider the following excerpt from
-link:../../admin_guide/manage_authorization_policy.html#viewing-roles-and-bindings[viewing
-a policy], showing rule sets for the *admin* and *basic-user*
-link:#roles[default roles]:
+the CLI].
+endif::[]
+ifdef::openshift-dedicated[]
+using the CLI.
+endif::[]
+For example, consider the following excerpt from viewing a policy, showing rule
+sets for the *admin* and *basic-user* link:#roles[default roles]:
 
 ====
 
@@ -61,9 +65,8 @@ basic-user		Verbs					Resources															Resource Names	Extension
 ----
 ====
 
-The following excerpt from
-link:../../admin_guide/manage_authorization_policy.html#viewing-roles-and-bindings[viewing
-policy bindings] shows the above roles bound to various users and groups:
+The following excerpt from viewing policy bindings shows the above roles bound
+to various users and groups:
 
 ====
 
@@ -186,36 +189,50 @@ TIP: Remember that link:authentication.html#users-and-groups[users
 and groups] can be associated with, or _bound_ to, multiple roles at the same
 time.
 
-These roles, including a matrix of the verbs and resources each are associated
-with, can be visualized in the cluster policy by using the CLI to
+Cluster administrators can visualize these roles, including a matrix of the
+verbs and resources each are associated using the CLI to
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#viewing-cluster-roles[view
-the cluster roles]. Additional *system:* roles are listed as well, which
+the cluster roles].
+endif::[]
+ifdef::openshift-dedicated[]
+view the cluster roles.
+endif::[]
+Additional *system:* roles are listed as well, which
 are used for various OpenShift system and component operations.
 
 By default in a local policy, only the binding for the *admin* role is
 immediately listed when using the CLI to
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#viewing-local-bindings[view
-local bindings]. However, if other default roles are added to users and groups
-within a local policy, they become listed in the CLI output, as well.
+local bindings].
+endif::[]
+ifdef::openshift-dedicated[]
+view local bindings.
+endif::[]
+However, if other default roles are added to users and groups within a local
+policy, they become listed in the CLI output, as well.
 
 If you find that these roles do not suit you, a *cluster-admin* user can create
 a `*policyBinding*` object named `_<projectname>_:default` with the CLI using a
 JSON file. This allows the project *admin* to bind users to roles that are
 defined only in the `_<projectname>_` local policy.
 
+ifdef::openshift-enterprise,openshift-origin[]
 [[updating-cluster-roles]]
 
 === Updating Cluster Roles
 
-After any link:../../install_config/upgrades.html[OpenShift cluster upgrade], the
-recommended default roles may have been updated. See the Administrator Guide for
-instructions on
+After any link:../../install_config/upgrades.html[OpenShift cluster upgrade],
+the recommended default roles may have been updated. See the Cluster
+Administration documentation for instructions on
 link:../../install_config/upgrades.html#updating-policy-definitions[updating the
 policy definitions] to the new recommendations using:
 
 ----
 $ oadm policy reconcile-cluster-roles
 ----
+endif::[]
 
 [[security-context-constraints]]
 
@@ -231,8 +248,13 @@ order to be accepted into the system. They allow an administrator to control the
 following:
 
 . Running of
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../install_config/install/prerequisites.html#security-warning[privileged
 containers].
+endif::[]
+ifdef::openshift-dedicated[]
+privileged containers.
+endif::[]
 . Capabilities a container can request to be added.
 . Use of host directories as volumes.
 . The SELinux context of the container.

architecture/additional_concepts/other_api_objects.adoc

@@ -249,8 +249,14 @@ this token, if any.
 
 === Identity
 When a user logs into OpenShift, they do so using a configured
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../install_config/configuring_authentication.html#identity-providers[identity
-provider]. This determines the user's identity, and provides that information to
+provider].
+endif::[]
+ifdef::openshift-dedicated[]
+identity provider. 
+endif::[]
+This determines the user's identity, and provides that information to
 OpenShift.
 
 OpenShift then looks for a `*UserIdentityMapping*` for that `*Identity*`:
@@ -295,8 +301,13 @@ given an `*OAuthAccessToken*` for the mapped `*User*`.
 
 === User
 A `*User*` represents an actor in the system. Users are granted permissions by
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#managing-role-bindings[adding
 roles to users or to their groups].
+endif::[]
+ifdef::openshift-dedicated[]
+adding roles to users or to their groups.
+endif::[]
 
 User objects are created automatically on first login, or can be created via the
 API.
@@ -368,8 +379,13 @@ methods to identify the same `*User*`.
 
 === Group
 A `*Group*` represents a list of users in the system. Groups are granted permissions by
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#managing-role-bindings[adding
 roles to users or to their groups].
+endif::[]
+ifdef::openshift-dedicated[]
+adding roles to users or to their groups.
+endif::[]
 
 .`*Group*` Object Definition
 ====

architecture/additional_concepts/sdn.adoc

@@ -17,7 +17,7 @@ cluster. This pod network is established and maintained by the
 ifdef::openshift-origin[]
 https://github.com/openshift/openshift-sdn[OpenShift SDN],
 endif::[]
-ifdef::openshift-enterprise[]
+ifdef::openshift-enterprise,openshift-dedicated[]
 OpenShift SDN,
 endif::[]
 which configures an overlay network using Open vSwitch (OVS).
@@ -41,11 +41,13 @@ all other pods in the cluster and vice versa.
 Following is a detailed discussion of the design and operation of OpenShift SDN,
 which may be useful for troubleshooting.
 
+ifdef::openshift-enterprise,openshift-origin[]
 [NOTE]
 ====
 Information on configuring the SDN on masters and nodes is available in
 link:../../install_config/configuring_sdn.html[Configuring the SDN].
 ====
+endif::[]
 
 [[sdn-design-on-masters]]
 == Design on Masters
@@ -181,5 +183,12 @@ As described before, VNID 0 is privileged in that traffic with any VNID is
 allowed to enter any pod assigned VNID 0, and traffic with VNID 0 is allowed to
 enter any pod. Only the *default* OpenShift project is assigned VNID 0; all
 other projects are assigned unique, isolation-enabled VNIDs. Cluster
-administrators can optionally  link:../../admin_guide/pod_network.html[control
-the pod network] for the project using the administrator CLI.
+administrators can optionally
+ifdef::openshift-enterprise,openshift-origin[]
+link:../../admin_guide/pod_network.html[control
+the pod network]
+endif::[]
+ifdef::openshift-dedicated[]
+control the pod network
+endif::[]
+for the project using the administrator CLI.

architecture/additional_concepts/storage.adoc

@@ -135,6 +135,7 @@ status of the volume.
 
 OpenShift supports the following `*PersistentVolume*` plug-ins:
 
+ifdef::openshift-enterprise,openshift-origin[]
 - link:../../install_config/persistent_storage/persistent_storage_nfs.html[NFS]
 - link:../../rest_api/kubernetes_v1.html#v1-hostpathvolumesource[HostPath]
 (single node testing only)
@@ -148,6 +149,19 @@ Cinder]
 Persistent Disk]
 - link:../../install_config/persistent_storage/persistent_storage_iscsi.html[iSCSI]
 - link:../../install_config/persistent_storage/persistent_storage_fibre_channel.html[Fibre Channel]
+endif::[]
+
+ifdef::openshift-dedicated[]
+- NFS
+- HostPath(single node testing only)
+- GlusterFS
+- Ceph RBD
+- OpenStack Cinder
+- AWS Elastic Block Store (EBS)
+- GCE Persistent Disk
+- iSCSI
+- Fibre Channel
+endif::[]
 
 [[pv-capacity]]
 

architecture/core_concepts/builds_and_image_streams.adoc

@@ -435,32 +435,36 @@ to run:
 [[insecure-registries]]
 
 === Importing Images from Insecure Registries
-An image stream can be configured to import tag and image metadata from an image
-repository that is signed with a self-signed certificate or from one using plain
-http instead of https. To do that, add `*openshift.io/image.insecureRepository*`
-annotation set to `*true*`. This setting will bypass certificate validation when
-connecting to registry.
+An image stream can be configured to import tag and image metadata from insecure
+image registries, such as those signed with a self-signed certificate or using
+plain HTTP instead of HTTPS.
 
-====
+To configure this, add the `*openshift.io/image.insecureRepository*` annotation
+and set it to *true*. This setting bypasses certificate validation when
+connecting to the registry:
 
+====
 [source,yaml]
 ----
 kind: ImageStream
 apiVersion: v1
 metadata:
   name: ruby
   annotations:
-    openshift.io/image.insecureRepository: "true"
+    openshift.io/image.insecureRepository: "true" <1>
   spec:
     dockerImageRepository: my.repo.com:5000/myimage
 ----
+<1> Set the `*openshift.io/image.insecureRepository*` annotation to *true*
 ====
 
+ifdef::openshift-enterprise,openshift-origin[]
 [IMPORTANT]
 ====
-The above definition will only affect importing tag and image metadata. For this
-image to be used in the cluster (be able to do `docker pull`) each node needs to
-have docker configured with `--insecure-registry` flag. See Installing Docker in
-link:../../install_config/install/prerequisites.html#host-preparation[Host Preparation]
-for information on the topic.
+The above definition only affects importing tag and image metadata. For this
+image to be used in the cluster (e.g., to be able to do a `docker pull`), each
+node must have Docker configured with the `--insecure-registry` flag. See
+link:../../install_config/install/prerequisites.html#host-preparation[Host
+Preparation] for information.
 ====
+endif::[]

architecture/core_concepts/projects_and_users.adoc

@@ -15,8 +15,13 @@ toc::[]
 Interaction with OpenShift is associated with a
 user. An OpenShift user object represents an
 actor which may be granted permissions in the system by
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#managing-role-bindings[adding
 roles to them or to their groups].
+endif::[]
+ifdef::openshift-dedicated[]
+adding roles to them or to their groups.
+endif::[]
 
 Several types of users can exist:
 
@@ -103,10 +108,21 @@ Each project scopes its own set of:
 
 Cluster administrators can link:../../dev_guide/projects.html[create projects]
 and
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/manage_authorization_policy.html#managing-role-bindings[delegate
-administrative rights] for the project to any member of the user community.
+administrative rights]
+endif::[]
+ifdef::openshift-dedicated[]
+delegate administrative rights
+endif::[]
+for the project to any member of the user community.
 Cluster administrators can also allow developers to create
+ifdef::openshift-enterprise,openshift-origin[]
 link:../../admin_guide/selfprovisioned_projects.html[their own projects].
+endif::[]
+ifdef::openshift-dedicated[]
+their own projects.
+endif::[]
 
 Developers and administrators can link:../../dev_guide/projects.html[interact
 with projects] using link:../../cli_reference/index.html[the CLI] or the