zalando / zalando/postgres-operator

Feature: Inherit annotation from label (or the other way around)

Open
#2,627 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
5.2k
Forks
1.1k
Avg merge
2d 16h
Merged PRs (30d)
3

Description

Please, answer some short questions which should help us to understand your problem / question better?

  • Which image of the operator are you using? no idea
  • Where do you run it - cloud or metal? Kubernetes or OpenShift? AWS K8s
  • Are you running Postgres Operator in production? yes
  • Type of issue? feature request

Status quo

The Postgres Operator configuration already has options inherited_annotations and inherited_labels, which both work in a similar way: An annotation or label on the Postgresql resource gets copied to a same-named annotation/label on the child resources which it creates (e.g. statefulsets and pods).

At Zalando, we are using inherited labels component,environment,team-id, and inherited annotation zalando.org/owning-application (instead of inheriting the application label, that instead is set to a fixed value).
So users are currently asked to set both the application label and the zalando.org/owning-application annotation on their Postgresql resource to the same value, where one of them should be enough.

Feature request

There should be a way of defining an inheritance of an annotation from a label (and the other way around, for completeness).

Potential configuration syntax:

   kubernetes:
      inherited_annotations:
        - "zalando.org/owning-application"
      inherited_labels:
        - component
        - environment
      inherited_annotations_from_labels:
        - annotation: "zalando.org/owning-application"
          from_label: "application"
          conflict_priority: -1
      inherited_labels_from_annotations:
        - label: "example"
          from_annotation: "example.org/example-label"
          conflict_priority: 3

The conflict priority would be used in case there are multiple sources for one label/annotation (with the ones coming from inherited_annotations/labels having priority 0).
Of course we could also just say that it's an error if there are conflicting sources for the same annotation/label, might be simpler.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the configuration and inheritance handling for inherited_annotations and inherited_labels. Define how annotation-to-label and label-to-annotation mappings resolve conflicting sources, then add coverage for the proposed configuration and conflict behavior; done means mapped metadata is copied to child resources as specified.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes, postgresql
Domain
backend, databases, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.