Skip to content

Fix hugo blockquote #1967

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

Merged
merged 2 commits into from
Jun 27, 2025
Merged

Fix hugo blockquote #1967

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1d71146
Fix hugo blockquote
MonkeyCanCode Jun 27, 2025
90796ab
Add license header
MonkeyCanCode Jun 27, 2025
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
12 changes: 5 additions & 7 deletions site/content/in-dev/unreleased/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,11 +31,10 @@ cascade:
# This file will NOT be copied into a new release's versioned docs folder.
---

{{< alert title="Warning" color="warning" >}}
These pages refer to the current state of the main branch, which is still under active development.

Functionalities can be changed, removed or added without prior notice.
{{< /alert >}}
> [!WARNING]
> These pages refer to the current state of the main branch, which is still under active development.
>
> Functionalities can be changed, removed or added without prior notice.

Apache Polaris (Incubating) is a catalog implementation for Apache Iceberg&trade; tables and is built on the open source Apache Iceberg&trade; REST protocol.

Expand Down Expand Up @@ -83,8 +82,7 @@ A catalog is configured with a storage configuration that can point to S3, Azure
You create *namespaces* to logically group Iceberg tables within a catalog. A catalog can have multiple namespaces. You can also create
nested namespaces. Iceberg tables belong to namespaces.

> **Important**
>
> [!Important]
> For the access privileges defined for a catalog to be enforced correctly, the following conditions must be met:
>
> - The directory only contains the data files that belong to a single table.
Expand Down
10 changes: 4 additions & 6 deletions site/content/in-dev/unreleased/access-control.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,8 +72,7 @@ in the catalog, such as catalog namespaces or tables. You can create one or more
You grant privileges to a catalog role and then grant the catalog role to a principal role to bestow the privileges to one or more service
principals.

> **Note**
>
> [!NOTE]
> If you update the privileges bestowed to a service principal, the updates won't take effect for up to one hour. This means that if you
> revoke or grant some privileges for a catalog, the updated privileges won't take effect on any service principal with access to that catalog
> for up to one hour.
Expand Down Expand Up @@ -104,9 +103,8 @@ This section describes the privileges that are available in the Polaris access c
roles are granted to principal roles, and principal roles are granted to service principals to specify the operations that service principals can
perform on objects in Polaris.

> **Important**
>
> You can only grant privileges at the catalog level. Fine-grained access controls are not available. For example, you can grant read
> [!IMPORTANT]
> You can only grant privileges at the catalog level. Fine-grained access controls are not available. For example, you can grant read
> privileges to all tables in a catalog but not to an individual table in the catalog.

To grant the full set of privileges (drop, list, read, write, etc.) on an object, you can use the *full privilege* option.
Expand Down Expand Up @@ -184,7 +182,7 @@ includes the following users:
create service principals. She can also create catalogs and
namespaces and configure access control for Polaris resources.

- **Bob:** A data engineer who uses Apache Spark&trade; to
- **Bob:** A data engineer who uses Apache Spark&trade; to
interact with Polaris.

- Alice has created a service principal for Bob. It has been
Expand Down
7 changes: 4 additions & 3 deletions site/content/in-dev/unreleased/admin-tool.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,8 +117,9 @@ java -jar runtime/admin/build/polaris-admin-*-runner.jar bootstrap -r realm1 -c

The `purge` command is used to remove realms and principal credentials from the Polaris server.

> Warning: Running the `purge` command will remove all data associated with the specified realms!
This includes all entities (catalogs, namespaces, tables, views, roles), all principal
> [!WARNING]
> Running the `purge` command will remove all data associated with the specified realms!
This includes all entities (catalogs, namespaces, tables, views, roles), all principal
credentials, grants, and any other data associated with the realms.

```shell
Expand All @@ -139,4 +140,4 @@ For example, to purge the `realm1` realm, you can run the following command:

```shell
java -jar runtime/admin/build/polaris-admin-*-runner.jar purge -r realm1
```
```
16 changes: 7 additions & 9 deletions site/content/in-dev/unreleased/command-line-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ options:
6. privileges
7. profiles

Each _command_ supports several _subcommands_, and some _subcommands_ have _actions_ that come after the subcommand in turn. Finally, _arguments_ follow to form a full invocation. Within a set of named arguments at the end of an invocation ordering is generally not important. Many invocations also have a required positional argument of the type that the _command_ refers to. Again, the ordering of this positional argument relative to named arguments is not important.
Each _command_ supports several _subcommands_, and some _subcommands_ have _actions_ that come after the subcommand in turn. Finally, _arguments_ follow to form a full invocation. Within a set of named arguments at the end of an invocation ordering is generally not important. Many invocations also have a required positional argument of the type that the _command_ refers to. Again, the ordering of this positional argument relative to named arguments is not important.

Some example full invocations:

Expand Down Expand Up @@ -159,7 +159,7 @@ polaris catalogs create \
--allowed-location s3://other-bucket/third_location \
--role-arn ${ROLE_ARN} \
my_other_catalog

polaris catalogs create \
--storage-type file \
--default-base-location file:///example/tmp \
Expand Down Expand Up @@ -250,7 +250,7 @@ polaris catalogs update --default-base-location s3://new-bucket/my_data my_catal

### Principals

The `principals` command is used to manage principals within Polaris.
The `principals` command is used to manage principals within Polaris.

`principals` supports the following subcommands:

Expand Down Expand Up @@ -572,7 +572,7 @@ The catalog-roles command is used to create, discover, and manage catalog roles
4. list
5. update
6. grant
7. revoke
7. revoke

#### create

Expand Down Expand Up @@ -734,7 +734,7 @@ polaris catalog-roles revoke --catalog sales_data contains_cc_info_catalog_role

### Namespaces

The `namespaces` command is used to manage namespaces within Polaris.
The `namespaces` command is used to manage namespaces within Polaris.

`namespaces` supports the following subcommands:

Expand Down Expand Up @@ -786,7 +786,7 @@ options:
##### Examples

```
polaris namespaces delete outer_namespace.inner_namespace --catalog my_catalog
polaris namespaces delete outer_namespace.inner_namespace --catalog my_catalog

polaris namespaces delete --catalog my_catalog outer_namespace
```
Expand Down Expand Up @@ -1164,7 +1164,7 @@ polaris profiles update dev

## Examples

This section outlines example code for a few common operations as well as for some more complex ones.
This section outlines example code for a few common operations as well as for some more complex ones.

For especially complex operations, you may wish to instead directly use the Python API.

Expand Down Expand Up @@ -1220,5 +1220,3 @@ for principal_role in ${principal_roles}; do
done
done
```


18 changes: 10 additions & 8 deletions site/content/in-dev/unreleased/configuration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,8 @@ This page provides information on how to configure Apache Polaris (Incubating).
otherwise, this information is valid both for Polaris Docker images (and Kubernetes deployments) as
well as for Polaris binary distributions.

> Note: for Production tips and best practices, refer to [Configuring Polaris for Production]({{% ref "configuring-polaris-for-production.md" %}}).
> [!NOTE]
> For Production tips and best practices, refer to [Configuring Polaris for Production]({{% ref "configuring-polaris-for-production.md" %}}).

First off, Polaris server runs on Quarkus, and uses its configuration mechanisms. Read Quarkus
[configuration guide](https://quarkus.io/guides/config) to get familiar with the basics.
Expand All @@ -48,7 +49,7 @@ The sources are listed below, from highest to lowest priority:
When using environment variables, there are two naming conventions:

1. If possible, just use the property name as the environment variable name. This works fine in most
cases, e.g. in Kubernetes deployments. For example, `polaris.realm-context.realms` can be
cases, e.g. in Kubernetes deployments. For example, `polaris.realm-context.realms` can be
included as is in a container YAML definition:
```yaml
env:
Expand Down Expand Up @@ -79,7 +80,7 @@ read-only mode, as Polaris only reads the configuration file once, at startup.

| Configuration Property | Default Value | Description |
|----------------------------------------------------------------------------------------|-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `polaris.persistence.type` | `relational-jdbc` | Define the persistence backend used by Polaris (`in-memory`, `relational-jdbc`, `eclipse-link` (deprecated)). See [Configuring Apache Polaris for Production)[{{% ref "configuring-polaris-for-production.md" %}}) |
| `polaris.persistence.type` | `relational-jdbc` | Define the persistence backend used by Polaris (`in-memory`, `relational-jdbc`, `eclipse-link` (deprecated)). See [Configuring Apache Polaris for Production)[{{% ref "configuring-polaris-for-production.md" %}}) |
| `polaris.persistence.relational.jdbc.max-retries` | `1` | Total number of retries JDBC persistence will attempt on connection resets or serialization failures before giving up. |
| `polaris.persistence.relational.jdbc.max_duaration_in_ms` | `5000 ms` | Max time interval (ms) since the start of a transaction when retries can be attempted. |
| `polaris.persistence.relational.jdbc.initial_delay_in_ms` | `100 ms` | Initial delay before retrying. The delay is doubled after each retry. |
Expand Down Expand Up @@ -124,7 +125,7 @@ There are non Polaris configuration properties that can be useful:
|------------------------------------------------------|---------------------------------|-----------------------------------------------------------------------------|
| `quarkus.log.level` | `INFO` | Define the root log level. |
| `quarkus.log.category."org.apache.polaris".level` | | Define the log level for a specific category. |
| `quarkus.default-locale` | System locale | Force the use of a specific locale, for instance `en_US`. |
| `quarkus.default-locale` | System locale | Force the use of a specific locale, for instance `en_US`. |
| `quarkus.http.port` | `8181` | Define the HTTP port number. |
| `quarkus.http.auth.basic` | `false` | Enable the HTTP basic authentication. |
| `quarkus.http.limits.max-body-size` | `10240K` | Define the HTTP max body size limit. |
Expand All @@ -139,7 +140,8 @@ There are non Polaris configuration properties that can be useful:
| `quarkus.management.root-path` | | Define the root path where `/metrics` and `/health` endpoints are based on. |
| `quarkus.otel.sdk.disabled` | `true` | Enable the OpenTelemetry layer. |

> Note: This section is only relevant for Polaris Docker images and Kubernetes deployments.
> [!NOTE]
> This section is only relevant for Polaris Docker images and Kubernetes deployments.

There are many other actionable environment variables available in the official Polaris Docker
image; they come from the base image used by Polaris, [ubi9/openjdk-21-runtime]. They should be used
Expand Down Expand Up @@ -169,8 +171,8 @@ Here are some examples:
| Example | `docker run` option |
|--------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
| Using another GC | `-e GC_CONTAINER_OPTIONS="-XX:+UseShenandoahGC"` lets Polaris use Shenandoah GC instead of the default parallel GC. |
| Set the Java heap size to a _fixed_ amount | `-e JAVA_OPTS_APPEND="-Xms8g -Xmx8g"` lets Polaris use a Java heap of 8g. |
| Set the maximum heap percentage | `-e JAVA_MAX_MEM_RATIO="70"` lets Polaris use 70% percent of the available memory. |
| Set the Java heap size to a _fixed_ amount | `-e JAVA_OPTS_APPEND="-Xms8g -Xmx8g"` lets Polaris use a Java heap of 8g. |
| Set the maximum heap percentage | `-e JAVA_MAX_MEM_RATIO="70"` lets Polaris use 70% percent of the available memory. |


## Troubleshooting Configuration Issues
Expand All @@ -184,5 +186,5 @@ quarkus.log.console.level=DEBUG
quarkus.log.category."io.smallrye.config".level=DEBUG
```

> [!IMPORTANT] This will print out all configuration values, including sensitive ones like
> [!IMPORTANT] This will print out all configuration values, including sensitive ones like
> passwords. Don't do this in production, and don't share this output with anyone you don't trust!
1 change: 0 additions & 1 deletion site/content/in-dev/unreleased/configuring-polaris-for-production.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -218,4 +218,3 @@ Leave out `FILE` to prevent its use. Only include the storage types your setup n

The [Polaris Evolution](../evolution) page discusses backward compatibility and
upgrade concerns.

8 changes: 4 additions & 4 deletions site/content/in-dev/unreleased/entities.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,19 +72,19 @@ For information on managing principal roles with the REST API or for more inform

## Catalog Role

Polaris catalog roles are labels that may be granted to [catalogs](#catalog). Each catalog may have one or more catalog roles, and the same catalog role may be granted to multiple catalogs. Catalog roles may be assigned based on the nature of data that will reside in a catalog, or by the groups of users and services that might need to access that data.
Polaris catalog roles are labels that may be granted to [catalogs](#catalog). Each catalog may have one or more catalog roles, and the same catalog role may be granted to multiple catalogs. Catalog roles may be assigned based on the nature of data that will reside in a catalog, or by the groups of users and services that might need to access that data.

Each catalog role may have multiple [privileges](#privilege) granted to it, and each catalog role can be granted to one or more [principal roles](#principal-role). This is the mechanism by which principals are granted access to entities inside a catalog such as namespaces and tables.

## Policy

Polaris policy is a set of rules governing actions on specified resources under predefined conditions. Polaris support policy for Iceberg table compaction, snapshot expiry, row-level access control, and custom policy definitions.
Polaris policy is a set of rules governing actions on specified resources under predefined conditions. Polaris support policy for Iceberg table compaction, snapshot expiry, row-level access control, and custom policy definitions.

Policy can be applied at catalog level, namespace level, or table level. Policy inheritance can be achieved by attaching one to a higher-level scope, such as namespace or catalog. As a result, tables registered under those entities do not need to be declared individually for the same policy. If a table or a namespace requires a different policy, user can assign a different policy, hence overriding policy of the same type declared at the higher level entities.
Policy can be applied at catalog level, namespace level, or table level. Policy inheritance can be achieved by attaching one to a higher-level scope, such as namespace or catalog. As a result, tables registered under those entities do not need to be declared individually for the same policy. If a table or a namespace requires a different policy, user can assign a different policy, hence overriding policy of the same type declared at the higher level entities.

## Privilege

Polaris privileges are granted to [catalog roles](#catalog-role) in order to grant principals with a given principal role some degree of access to catalogs with a given catalog role. When a privilege is granted to a catalog role, any principal roles granted that catalog role receive the privilege. In turn, any principals who are granted that principal role receive it.
Polaris privileges are granted to [catalog roles](#catalog-role) in order to grant principals with a given principal role some degree of access to catalogs with a given catalog role. When a privilege is granted to a catalog role, any principal roles granted that catalog role receive the privilege. In turn, any principals who are granted that principal role receive it.

A privilege can be scoped to any entity inside a catalog, including the catalog itself.

Expand Down
Loading
Loading