mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
removing {nbsp}
This commit is contained in:
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide describes how cluster administrators can extend their {product-title}
|
||||
cluster by creating and managing Custom Resource Definitions (CRDs).
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ include::modules/common-attributes.adoc[]
|
||||
:context: crd-managing-resources-from-crds
|
||||
|
||||
toc::[]
|
||||
{nbsp} +
|
||||
|
||||
This guide describes how developers can manage Custom Resources (CRs) that come
|
||||
from Custom Resource Definitions (CRDs).
|
||||
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
A _deployment strategy_ is a way to change or upgrade an application. The aim
|
||||
is to make the change without downtime in a way that the user barely notices the
|
||||
improvements.
|
||||
|
||||
@@ -4,7 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: deployment-operations
|
||||
|
||||
toc::[]
|
||||
{nbsp} +
|
||||
|
||||
[id='deploymentconfig-operations']
|
||||
== Managing DeploymentConfigs
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Deployment strategies provide a way for the application to evolve. Some
|
||||
strategies use DeploymentConfigs to make changes that are seen by users of all
|
||||
routes that resolve to the application. Other advanced strategies, such as the
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
_Deployments_ and _DeploymentConfigs_ in {product-title} are API objects that
|
||||
provide two similar but different methods for fine-grained management over
|
||||
common user applications. They are comprised of the following separate API
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Cluster administrators can idle applications to reduce resource consumption.
|
||||
This is useful when the cluster is deployed on a public cloud where cost is
|
||||
related to resource consumption.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide outlines Ansible support in the Operator SDK and walks Operator
|
||||
authors through examples building and running Ansible-based Operators with the
|
||||
`operator-sdk` CLI tool that use Ansible playbooks and modules.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide documents the Operator SDK CLI commands and their syntax:
|
||||
|
||||
----
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
A _ClusterServiceVersion_ (CSV) is a YAML manifest created from Operator
|
||||
metadata that assists the Operator Lifecycle Manager (OLM) in running the
|
||||
Operator in a cluster. It is the metadata that accompanies an Operator container
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide outlines the basics of the Operator SDK and walks Operator authors
|
||||
with cluster administrator access to a Kubernetes-based cluster (such as
|
||||
{product-title}) through an example of building a simple Go-based Memcached
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide outlines Helm chart support in the Operator SDK and walks Operator
|
||||
authors through an example of building and running an Nginx Operator with the
|
||||
`operator-sdk` CLI tool that uses an existing Helm chart.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide describes how to migrate an Operator project built using Operator SDK
|
||||
v0.0.x to the project structure required by
|
||||
link:https://github.com/operator-framework/operator-sdk/releases[Operator SDK v0.1.0].
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide describes the built-in monitoring support provided by the Operator
|
||||
SDK using the Prometheus Operator and details usage for Operator authors.
|
||||
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide outlines the architecture of the Operator Lifecycle Manager (OLM) and
|
||||
OperatorHub and walks cluster administrators through an example of installing
|
||||
and subscribing a cluster to Operators from the OperatorHub.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This guide walks developers through an example of creating applications from an
|
||||
installed Operator using the {product-title} 4.0 web console.
|
||||
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
[.lead]
|
||||
Conceptually, _Operators_ take human operational knowledge and encode it into
|
||||
software that is more easily shared with consumers.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Over time, API objects created in {product-title} can accumulate in the
|
||||
cluster's etcd data store through normal user operations, such as when building
|
||||
and deploying applications.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
A multi-project quota, defined by a ClusterResourceQuota object, allows quotas
|
||||
to be shared across multiple projects. Resources used in each selected project
|
||||
are aggregated and that aggregate is used to limit resources across all the
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
A _resource quota_, defined by a ResourceQuota object, provides constraints that
|
||||
limit aggregate resource consumption per project. It can limit the quantity of
|
||||
objects that can be created in a project by type, as well as the total amount of
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
A _resource quota_, defined by a ResourceQuota object, provides constraints that
|
||||
limit aggregate resource consumption per project. It can limit the quantity of
|
||||
objects that can be created in a project by type, as well as the total amount of
|
||||
|
||||
@@ -8,8 +8,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: architecture
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
This assembly is a temporary placeholder to port the valid information from
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: web-console
|
||||
toc::[]
|
||||
|
||||
{nbsp}
|
||||
|
||||
The {product-title} web console is a user interface accessible from a web browser.
|
||||
Developers can use the web console to visualize, browse, and manage the contents
|
||||
of projects.
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-internal-oauth
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
Configuring these options will need to change because they're set in the master
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/ldap-failover-overview.adoc[]
|
||||
|
||||
include::modules/ldap-failover-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-user-agent
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/user-agent-overview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/user-agent-configuring.adoc[leveloffset=+1]
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-basic-authentication-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure a `basic-authentication` identity provider for users to log in to
|
||||
{product-title} with credentials validated against a remote identity provider.
|
||||
Basic authentication is a generic backend integration mechanism.
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-github-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure a `github` identity provider to validate user names and passwords
|
||||
against GitHub or GitHub Enterprise's OAuth authentication server. OAuth
|
||||
facilitates a token exchange flow between
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-gitlab-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure a `gitlab` identity provider to use
|
||||
link:https://gitlab.com/[GitLab.com] or any other GitLab instance as an identity
|
||||
provider. If you use GitLab version 7.7.0 to 11.0, you connect using the
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-google-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure a `google` identity provider using
|
||||
link:https://developers.google.com/identity/protocols/OpenIDConnect[Google's OpenID Connect integration].
|
||||
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-htpasswd-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure the `htpasswd` identity provider to validate user names and passwords
|
||||
against a flat file generated using
|
||||
link:http://httpd.apache.org/docs/2.4/programs/htpasswd.html[`htpasswd`].
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-keystone-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure the `keystone` identity provider to integrate
|
||||
your {product-title} cluster with Keystone to enable shared authentication with
|
||||
an OpenStack Keystone v3 server configured to store users in an internal
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-ldap-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure the `ldap` identity provider to validate user names and passwords
|
||||
against an LDAPv3 server, using simple bind authentication.
|
||||
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-oidc-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure an `oidc` identity provider to integrate with an OpenID Connect
|
||||
identity provider using an
|
||||
link:http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow].
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-request-header-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Configure a `request-header` identity provider to identify users from request
|
||||
header values, such as `X-Remote-User`. It is typically used in combination with
|
||||
an authenticating proxy, which sets the request header value.
|
||||
|
||||
@@ -4,9 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-internal-oauth
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
|
||||
include::modules/security-context-constraints-about.adoc[leveloffset=+1]
|
||||
|
||||
// I should add a module about installing the OC command line.
|
||||
|
||||
@@ -4,6 +4,4 @@ include::modules/common-attributes.adoc[]
|
||||
:context: configuring-internal-oauth
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/tokens-scoping-about.adoc[leveloffset=+1]
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: understanding-service-accounts
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/service-accounts-overview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/service-accounts-dedicated-admin-role.adoc[leveloffset=+1]
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: understanding-authentication
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
For users to interact with {product-title}, they must first authenticate
|
||||
to the cluster. The authentication layer identifies the user associated with requests to the
|
||||
{product-title} API. The authorization layer then uses information about the
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: understanding-identity-provider
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
The {product-title} master includes a built-in OAuth server. Developers and
|
||||
administrators obtain OAuth access tokens to authenticate themselves to the API.
|
||||
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/rbac-overview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/rbac-projects-namespaces.adoc[leveloffset=+1]
|
||||
|
||||
@@ -4,6 +4,4 @@ include::modules/common-attributes.adoc[]
|
||||
:context: using-service-accounts-as-oauth-client
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/service-accounts-as-oauth-clients.adoc[leveloffset=+1]
|
||||
include::modules/service-accounts-as-oauth-clients.adoc[leveloffset=+1]
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: using-service-accounts
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/service-accounts-overview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/service-accounts-default.adoc[leveloffset=+1]
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Before you can install {product-title}, you must configure an
|
||||
Amazon Web Services (AWS) account.
|
||||
|
||||
|
||||
@@ -5,9 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
|
||||
In {product-title} version {product-version}, you can install a customized
|
||||
cluster on Amazon Web Services (AWS).
|
||||
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
In {product-title} version {product-version}, you can install a cluster on
|
||||
Amazon Web Services (AWS) that uses the default configuration options.
|
||||
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
You can remove a cluster that you deployed to Amazon Web Services (AWS).
|
||||
|
||||
include::modules/installation-uninstall-aws.adoc[leveloffset=+1]
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
You can install {product-title} version {product-version} on existing Red Hat
|
||||
Enterprise Linux (RHEL) hosts. This is a BYO, or bring-your-own hosts, installation.
|
||||
|
||||
|
||||
@@ -5,7 +5,5 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
We don't know how this will be managed at release of 4.0, but this topic
|
||||
will need to say something.
|
||||
will need to say something.
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Applying autoscaling to a {product-title} cluster involves deploying a
|
||||
ClusterAutoscaler and then deploying MachineAutoscalers for each Machine type
|
||||
in your cluster.
|
||||
|
||||
@@ -5,8 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
You can create a MachineSet to host only infrastructure components.
|
||||
You apply specific Kubernetes labels to these Machines and then
|
||||
update the infrastructure components to run on only those Machines.These
|
||||
|
||||
@@ -5,7 +5,4 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/machineset-creating.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/machineset-creating.adoc[leveloffset=+1]
|
||||
@@ -5,7 +5,4 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/machineset-manually-scaling.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/machineset-manually-scaling.adoc[leveloffset=+1]
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp}
|
||||
Learn about the Node Tuning Operator and how you can use it to manage node-level
|
||||
tuning by orchestrating the tuned daemon.
|
||||
|
||||
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: comparing_v3_v4
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
This is a placeholder for the high-level information about {product-title} 4 that is
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
The OpenShift SDN uses Open vSwitch, Virtual Extensible LAN (VXLAN) tunnels,
|
||||
OpenFlow rules, and iptables. This network can be tuned by using jumbo frames,
|
||||
network interface cards (NIC) offloads, multi-queue, and ethtool settings.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Containers can specify compute resource requests and limits. Requests are used
|
||||
for scheduling your container and provide a minimum service guarantee. Limits
|
||||
constrain the amount of compute resource that may be consumed on your node.
|
||||
|
||||
@@ -18,7 +18,6 @@ ifdef::openshift-enterprise[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Optimizing storage helps to minimize storage use across all resources. By
|
||||
optimizing storage, administrators help ensure that existing storage resources
|
||||
are working in an efficient manner.
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Consider the following object limits when you plan your {product-title} cluster.
|
||||
|
||||
These limits are based on on the the largest possible cluster. For smaller
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
This topic provides recommended host practices for {product-title}.
|
||||
|
||||
include::modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc[leveloffset=+1]
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
{product-title} exposes metrics that can be collected and stored in back-ends by
|
||||
the
|
||||
link:https://github.com/openshift/cluster-monitoring-operator[*cluster-monitoring-operator*].
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Cluster Loader is a tool that deploys large numbers of various objects to a
|
||||
cluster, which creates user-defined cluster objects. Build, configure, and run
|
||||
Cluster Loader to measure performance metrics of your {product-title} deployment
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
Learn about the Node Tuning Operator and how you can use it to manage node-level
|
||||
tuning by orchestrating the tuned daemon.
|
||||
|
||||
@@ -13,7 +12,7 @@ include::modules/node-tuning-operator.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/accessing-an-example-cluster-node-tuning-operator-specification.adoc[leveloffset=+1]
|
||||
|
||||
:FeatureName: Custom profiles for custom tuning specification
|
||||
:FeatureName: Custom profiles for custom tuning specification
|
||||
include::modules/technology-preview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/custom-tuning-specification.adoc[leveloffset=+1]
|
||||
|
||||
@@ -4,10 +4,8 @@ include::modules/common-attributes.adoc[]
|
||||
:context: creating-project-other-user
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
Impersonation allows you to create a project as a different user.
|
||||
|
||||
include::modules/authentication-api-impersonation.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/impersonation-project-creation.adoc[leveloffset=+1]
|
||||
include::modules/impersonation-project-creation.adoc[leveloffset=+1]
|
||||
@@ -4,8 +4,6 @@ include::modules/common-attributes.adoc[]
|
||||
:context: impersonating-system-admin
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
|
||||
include::modules/authentication-api-impersonation.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/impersonation-system-admin-user.adoc[leveloffset=+1]
|
||||
|
||||
@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{nbsp} +
|
||||
A _project_ allows a community of users to organize and manage their content in
|
||||
isolation from other communities.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user