Compare commits

...

3 Commits

Author SHA1 Message Date
Max Eisner
3b22cd68f2
Merge 78d02d6803 into 9967e2caab 2026-08-12 16:03:08 +05:30
Gabriele Bartolini
9967e2caab
chore: sync CODEOWNERS with cnpg-infra policy (#1047)
Regenerates this repo's CODEOWNERS from cloudnative-pg/cnpg-infra's
`componentowners-policy.yaml`, the org's tracked desired state for
CODEOWNERS content.

- Routes ownership through this repo's dedicated GitHub owners team
instead of hardcoded usernames, so membership changes are picked up
automatically.
- Any path-scoped rule now also includes the repo's general owners, so a
path rule adds reviewers rather than silently replacing the `*` rule's
owners for that subtree (CODEOWNERS only honors the last matching
pattern, it does not merge).

See cloudnative-pg/cnpg-infra for the policy this is generated from.

Assisted-by: Claude

Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
2026-08-06 19:30:12 +10:00
Max Eisner
78d02d6803
docs: add IRSA instructions
Signed-off-by: Max Eisner <4730112+max-ae@users.noreply.github.com>
2025-08-18 13:36:01 +02:00
3 changed files with 25 additions and 4 deletions

View File

@ -1,5 +1,9 @@
# The CODEOWNERS file is used to define individuals or teams that are # This file is generated from componentowners-policy.yaml in
# responsible for code in a repository. For details, please refer to # cloudnative-pg/cnpg-infra — do not hand-edit, propose changes there instead.
# https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners #
# Path-scoped rules below always include the repo's own general owners
# (the "*" line) in addition to their own specific teams/users, since
# CODEOWNERS only honors the LAST matching pattern for a given path —
# it does not merge an earlier, less-specific rule into a later one.
* @leonardoce @mnencia @gbartolini @fcanovai @armru @NiccoloFei * @cloudnative-pg/plugin-barman-cloud-owners

View File

@ -103,6 +103,10 @@ As you can see, the contents of `barmanObjectStore` have been copied directly
under the `configuration` field of the `ObjectStore` resource, using the same under the `configuration` field of the `ObjectStore` resource, using the same
secret references. secret references.
### IAM Role for Service Account (IRSA)
If you use IRSA, you need to configure the `ObjectStore` to utilize the correct role as described in the [`Object Store Reference`](object_stores.md#iam-role-for-service-account-irsa).
## Step 2: Update the `Cluster` for plugin WAL archiving ## Step 2: Update the `Cluster` for plugin WAL archiving
Once the `ObjectStore` resource is in place, update the `Cluster` resource as Once the `ObjectStore` resource is in place, update the `Cluster` resource as

View File

@ -111,6 +111,19 @@ spec:
[...] [...]
``` ```
In addition, configure the `ObjectStore` to inherit permissions from the IAM role referenced in the service account:
```yaml
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
[...]
spec:
configuration:
s3Credentials:
inheritFromIAMRole: true
```
### S3 Lifecycle Policy ### S3 Lifecycle Policy
Barman Cloud uploads backup files to S3 but does not modify them afterward. Barman Cloud uploads backup files to S3 but does not modify them afterward.