Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edits to Docs/pem/licensing page #6106 #6244

Merged
merged 1 commit into from
Nov 21, 2024
Merged

Edits to Docs/pem/licensing page #6106 #6244

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 22 additions & 20 deletions product_docs/docs/pem/9/considerations/licensing.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,45 +15,47 @@ instances generally incurs no additional license costs.

To use PEM, you must have an EDB Standard or Enterprise subscription.

Any Postgres servers you monitor using PEM (whether by installing the
PEM Agent locally, through Remote Monitoring, or by making a client
connection from the PEM web application) must be covered by an EDB
Standard or Enterprise subscription.
Any Postgres servers you monitor using PEM must be covered by an EDB
Standard or Enterprise subscription. This is true whether you're installing the
PEM agent locally, through remote monitoring, or by making a client
connection from the PEM web application.

Non-Postgres servers that do not otherwise consume cores (for example
Non-Postgres servers that don't otherwise consume cores (for example
PGD Proxy nodes or machines running Barman) may be monitored by PEM. No
additional cores are consumed by monitoring such servers with PEM.

The Postgres instance used as the PEM backend does not consume cores
The Postgres instance used as the PEM backend doesn't consume cores
from your subscription. Likewise, no cores are consumed by any other PEM
components. All these components are covered by your support agreement.

## Examples

### Adding PEM to a fully-supported environment
A customer with an Enterprise subscription for 32 cores has 8 x 4-core
servers running EDB Postgres Advanced Server (EPAS), thereby fully
consuming their 32 cores. This customer may install PEM on a fifth
server and use it to monitor their 8 EPAS servers. This requires no
change to their subscription as the PEM server does not consume cores
and the monitored EPAS instances are already fully covered.
### Adding PEM to a fully supported environment

Suppose a customer with an Enterprise subscription for 32 cores has 8 x 4-core
servers running EDB Postgres Advanced Server, thereby fully
consuming their 32 cores. This customer can install PEM on a fifth
server and use it to monitor their 8 EDB Postgres Advanced Server servers. This configuration requires no
change to their subscription, as the PEM server doesn't consume cores,
and the monitored EDB Postgres Advanced Server instances are already fully covered.

Likewise, if this customer added a Barman server and connected it to PEM
for monitoring, they would consume no additional cores.

### Adding unsupported servers to PEM
A customer with a Standard subscription for 36 cores has PEM and 6 x
6-core servers running PostgreSQL covered by EDB support - thereby
consuming their 36 cores as in the example above.

The customer also has 10 x 2-core PostgreSQL servers that are not
Suppose a customer with a Standard subscription for 36 cores has PEM and 6 x
6-core servers running PostgreSQL covered by EDB support, thereby
consuming their 36 cores, as in the previous example.

The customer also has 10 x 2-core PostgreSQL servers that aren't
covered by any EDB subscription. These servers must not be monitored by
PEM as they are not covered by a Standard or Enterprise subscription. If
the customer wishes to monitor these servers they must add a further 20
PEM, as they aren't covered by a Standard or Enterprise subscription. If
the customer wants to monitor these servers, they must add 20 more
cores to their subscription.

!!! Note
An EDB Community 360 subscription for the additional 20 cores is not
An EDB Community 360 subscription for the additional 20 cores isn't
sufficient. Servers monitored by PEM must be covered by Standard or
Enterprise.
!!!
35 changes: 17 additions & 18 deletions product_docs/docs/postgres_for_kubernetes/1/installation_upgrade.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,37 +17,37 @@ originalFilePath: 'src/installation_upgrade.md'
### Obtaining an EDB subscription token

!!! Important
You must obtain an EDB subscription token to install EDB Postgres for Kubernetes. Without a token, you will not be able to access the EDB private software repositories.
You must obtain an EDB subscription token to install EDB Postgres for Kubernetes. You can only access the EDB private software repositories if you have a token.

Installing EDB Postgres for Kubernetes requires an EDB Repos 2.0 token to gain access to the EDB private software repositories.

You can obtain the token by visiting your [EDB Account Profile](https://www.enterprisedb.com/accounts/profile). You will have to sign in if you are not already logged in.
You can obtain the token by visiting your [EDB Account Profile](https://www.enterprisedb.com/accounts/profile). You must sign in if you're not already logged in.

Your account profile page displays the token to use next to **Repos 2.0 Token** label. By default, the token is obscured, click the "Show" button (an eye icon) to reveal it.
Your account profile page displays the token to use next to the **Repos 2.0 Token** label. By default, the token is obscured. Select **Show** (the eye icon) to reveal it.

Your token entitles you to access one of two repositories: standard or enterprise.

* `standard` - Includes the operator and the EDB Postgres Extended operand images.
* `enterprise` - Includes the operator and the EDB Postgres Advanced and EDB Postgres Extended operand images.
* `standard` — Includes the operator and the EDB Postgres Extended operand images.
* `enterprise` — Includes the operator and the EDB Postgres Advanced and EDB Postgres Extended operand images.

Set the relevant value, determined by your subscription, as an environment variable `EDB_SUBSCRIPTION_PLAN`.
Set the relevant value, determined by your subscription, as an environment variable `EDB_SUBSCRIPTION_PLAN`:

```shell
EDB_SUBSCRIPTION_PLAN=enterprise
```

then set the Repos 2.0 token to an environment variable `EDB_SUBSCRIPTION_TOKEN`.
Then set the Repos 2.0 token to an environment variable `EDB_SUBSCRIPTION_TOKEN`:

```shell
EDB_SUBSCRIPTION_TOKEN=<your-token>
```

!!! Warning
The token is sensitive information. Please ensure that you don't expose it to unauthorized users.
The token is sensitive information. Ensure that you don't expose it to unauthorized users.

You can now proceed with the installation.

### Using the Helm Chart
### Using the Helm chart

The operator can be installed using the provided [Helm chart](https://github.com/EnterpriseDB/edb-postgres-for-kubernetes-charts).

Expand All @@ -58,16 +58,15 @@ through a YAML manifest applied via `kubectl`.

#### Install the EDB pull secret

Before installing EDB Postgres for Kubernetes, you need to create a pull secret for EDB software in the `postgresql-operator-system` namespace.
Before installing EDB Postgres for Kubernetes, you need to create a pull secret for EDB software in the `postgresql-operator-system` namespace. The pull secret needs to be saved in the namespace where the operator will reside.


The pull secret needs to be saved in the namespace where the operator will reside. Create the `postgresql-operator-system` namespace using this command:
Create the `postgresql-operator-system` namespace:

```shell
kubectl create namespace postgresql-operator-system
```

To create the pull secret itself, run the following command:
Create the pull secret:

```shell
kubectl create secret -n postgresql-operator-system docker-registry edb-pull-secret \
Expand All @@ -78,13 +77,13 @@ kubectl create secret -n postgresql-operator-system docker-registry edb-pull-sec

#### Install the operator

Now that the pull-secret has been added to the namespace, the operator can be installed like any other resource in Kubernetes,
Now that the pull secret has been added to the namespace, the operator can be installed like any other resource in Kubernetes,
through a YAML manifest applied via `kubectl`.

There are two different manifests available depending on your subscription plan:
Two different manifests are available, depending on your subscription plan:

- Standard: The [latest standard operator manifest](https://get.enterprisedb.io/pg4k/pg4k-standard-1.24.1.yaml).
- Enterprise: The [latest enterprise operator manifest](https://get.enterprisedb.io/pg4k/pg4k-enterprise-1.24.1.yaml).
- Standard &mdash; The [latest standard operator manifest](https://get.enterprisedb.io/pg4k/pg4k-standard-1.24.1.yaml).
- Enterprise &mdash; The [latest enterprise operator manifest](https://get.enterprisedb.io/pg4k/pg4k-enterprise-1.24.1.yaml).

You can install the manifest for the latest version of the operator by running:
You can install the [latest operator manifest](https://get.enterprisedb.io/cnp/postgresql-operator-1.24.1.yaml)
Expand Down Expand Up @@ -115,7 +114,7 @@ kubectl cnp install generate \
> cnp_for_specific_namespace.yaml
```

Please refer to ["`cnp` plugin"](./kubectl-plugin.md#generation-of-installation-manifests) documentation
See the ["`cnp` plugin"](./kubectl-plugin.md#generation-of-installation-manifests) documentation
for a more comprehensive example.

!!! Warning
Expand Down