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

Databases and clusters should be created in the same namespace as the TPR #8

Closed
pst opened this issue Apr 16, 2017 · 6 comments
Closed

Comments

@pst
Copy link

pst commented Apr 16, 2017

I have two clusters defined as TPRs. One in the default namespace and one in the pgtest namespace.

$ kubectl get pgcluster --all-namespaces
NAMESPACE   NAME               KIND
default     pg-orange-jaguar   PgCluster.v1.crunchydata.com
pgtest      pg-pink-whale      PgCluster.v1.crunchydata.com

However, all deployments are created in the default namespace.

$ kubectl get deploy --all-namespaces
NAMESPACE         NAME                          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
default           pg-orange-jaguar              1         1         1            0           35m
default           pg-orange-jaguar-replica      2         2         2            0           35m
default           pg-pink-whale                 1         1         1            0           15m
default           pg-pink-whale-replica         2         2         2            0           15m

It's not clear to me what the model chosen here is. Do I need one operator per pgcluster, one operator per k8s namespaces or one operator per k8s cluster? Optimally I think the operator should only need to be deployed once per k8s cluster and then I can create multiple pgclusters in multiple namespaces.

@jmccormick2001
Copy link
Contributor

thanks, right now the operator is designed to be run in a single namespace and service that namespace, but I agree with you that having it be configured to run against all namespaces would be a nice feature to have, some will want this and others will not I assume. I think its a valid feature to support.

@pst
Copy link
Author

pst commented Apr 18, 2017

Thanks for your quick reply. My feedback is two-fold though. The long term aspect but also the currently it seems broken. Deploying the operator in some other namespace than default still puts the cluster in default. I think it's because the Deployment metadata has no namespace in the template (https://github.com/CrunchyData/postgres-operator/blob/master/conf/postgres-operator/cluster/1/cluster-deployment.json#L4). Unless I'm missing something.

@jmccormick2001
Copy link
Contributor

ah, thanks, appears to be a bug, it should adjust to the namespace defined in the config

@StephenSorriaux
Copy link
Contributor

Namespace used by postgres-operator to create pg deployment and replicas is the env var "NAMESPACE" of the postgres-operator deployment which refers to its metadata.namespace: https://github.com/CrunchyData/postgres-operator/blob/master/examples/operator/deployment.json#L24
It should take the namespace where the postgres-operator deployment is created, that is why you need 1 postgres-operator deployment per namespace.

I'm not sure why it is not the case here, I will take a look at this problem

@jmccormick2001
Copy link
Contributor

I placed some changes into master that should fix this, everything should run in a single namespace...FYI, I'm planning a new release on Friday if all goes as planned....

@jmccormick2001
Copy link
Contributor

should be fixed in the latest release (1.1).

andrewlecuyer pushed a commit to andrewlecuyer/postgres-operator that referenced this issue Jul 7, 2021
Per Golang source[1], the PEM encryption scheme is being
deprecrated due to various issues with PEM encryption
itself, which itself is based on RFC 1423.

The "ideal world" would use PKCS CrunchyData#8 encryption as defined
in RFC 5208. However, given using key encryption is a bit
superfluous in Kubernetes based on how Secrets work and
are available within a namespace, we can review this later.

[1] golang/go@57af974
cbandy referenced this issue in cbandy/postgres-operator Nov 11, 2021
JDBC. FIXME: should it go into the Secrets now?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants