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.

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

pgo - show ready state in output #11

Closed
jmccormick2001 opened this issue Apr 27, 2017 · 1 comment
Closed

pgo - show ready state in output #11

jmccormick2001 opened this issue Apr 27, 2017 · 1 comment

Comments

@jmccormick2001
Copy link
Contributor

in the pgo show command output, show the ready state as well as the pod phase (currently).

@jmccormick2001
Copy link
Contributor Author

merged in fix to show ready state of containers within a pod for database/cluster show command output.

andrewlecuyer added a commit to andrewlecuyer/postgres-operator that referenced this issue Jul 7, 2021
* Reconcile pgBackRest Repository Host

This is the initial commit for reconciling a pgBackRest dedicated
repository host via a PostgresCluster custom resource.  Specifically,
upon the creation of a PostgresCluster custom resource containing the
proper pgBackRest repository host configuration, a StatefulSet is now
generated that deploys the 'crunchy-pgbackrest' container as needed
to run a dedicated pgBackRest repository host.  At this time the
'crunchy-pgbackrest' container is minimally configured as needed to
successfully deploy the 'crunchy-pgbackrest' container, and therefore
successfully implement the controller design and architecture included
within this commit.  This includes the following:

- pgBackRest reconciliation logic based on the creation, modification
and deletion of PostgresCluster custom resources and other native
Kubernetes resources (e.g. reacting to StatefulSet changes)
- PostgresCluster ownership reference management (includes adoption and
orphaning logic)
- PostgresCluster status and condition management (i.e. creating and
updating status fields and any any associated conditions)
- Kubernetes event generation (i.e. creating pertinent "warning" and
"normal" events during reconciliation)

In support of the above, the PostgresCluster custom resource has also
been updated to include a pgBackRest "archive" configuration section,
under which a repository host configuration can be defined.  This
allows users to define a PostgresCluster custom resource (e.g. using
the example PostgresCluster within the repository, which has also been
updated via this commit) that results in the deployment of a pgBackRest
repository host.  Additionally, a pgBackRest status is now also
defined for the PostgresCluster custom resource, which is leveraged to
set the proper pgBackRest status and any associated pgBackRest
conditions when reconciling a PostgresCluster.

It should be noted that in general, the design and architecture for
this commit is influenced by the design an architecture of various
Kubernetes controllers within the Kubernetes "apps" package (as planned
for use by the PostgreSQL Operator).  This includes controllers for
resources such as StatefulSets, Deployments and ReplicaSets, with the
ultimate goal of ensuring a consistent end-user experience for the
PostgresCluster controller that aligns with the overall design of
Kubernetes and its controllers.

And finally, please note the initial design for deploying a pgBackRest
repository host assumes there will a single repository host defined for
a PostgresCluster, although certain aspects of the API are defined in a
manner that assumes it will eventually be possible to define more than
one repository host.  For instance, this commit implements a condition
type called "RepoHostsReady" (plural).

Issue: [ch9795]

* Miscellaneous Updates

Includes the following:

- Descriptions for any new PostgresCluster types no longer start
with the variable name to ensure field descriptions are defined in the
same manner as those for native Kubernetes resources
- Full decoupling of the Controller Ref Manager, which now compliments
the "Owns()" function for StatefulSets instead of replacing it
- Helpers client.FieldOwner() and client.ForceOwnership are now used
with all Server-Side Applies
- A check is no longer done to determine if the pgBackRest repo host
needs to be reconciled; a Server-Side Apply is simply run for the repo
host each time a PostgresCluster is reconciled
- SetStatusCondition() is now used to update PostgresCluster status
conditions (please note the observedGeneration will not be properly set
via this function until apimachinery is updated v0.20)
- Documentation for finalizers is now referenced where finalizers
can/will be run in the PostgresCluster Reconcile() function
- The comment for the VolumeSpec type now references the "union/oneOf"
proposal
- Refactoring and realignment with existing PostgresCluster controller
design

* TestPostgresClusterDefault Updates for Repo Host

Test TestPostgresClusterDefault() now defines the expected structure
for a default PostgresCluster resource that inlcudes the pgBackRest
fields that should now be inlcuded to reconcile pgBackRest (and more
specifically a pgBackRest repository host).

* apply() func & General Refactor

pgBackRest repo reconciliation now utilizes the apply() function in the
"postgrescluster" package to ensure Server-Side Apply patches are
properly formed.  Also some general refactoring.

* Cleanup & Refactoring

Removes the value from 'spec.archive.pgbackrest.image' in the example
postgrescluster.yaml file, adds pgBackRest labels to label tests in the
naming package, and the metav1.IsControlledBy() function is now used
to check resource ownership.  Also includes general cleanup.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant