Hello @christopher ,
it will not be in Oct-Dec release, but will land in Q1’24. The release scope for Q4’23 is already secured and in dev. Sorry for bringing bad news.
Hello @christopher ,
it will not be in Oct-Dec release, but will land in Q1’24. The release scope for Q4’23 is already secured and in dev. Sorry for bringing bad news.
Hello Sergey,
OK… I understand. Unfortunately I cannot wait until Q1 2024 to go to production. We have already delayed our migration to November.
So… al alternative for us is to build our own database image that already includes the dictionaries that we need. Is is documented somewhere how one might build their own percona Postgres image for use with your operator? I do not see anything in Github or within the operator repo. Can you provide more information.
Alternately I suppose we could clone and add the appropriate functionality to the operator ourself. That might be a better approach for both of us. Do you have guidelines on submitting patches?
Also… have you thought further on your sidecar suggestion, as noted above, I do not see how that could possibly work but you seemed to feel that there was a way. Did you find a way?
Thanks
Chris
Thanks
Chris
I tried it with sidecar and it does not work.
As for your question about Dockerfiles, you can find them here: https://github.com/percona/percona-docker/tree/main/postgresql-containers
Use this dockerfile for PGv2 Operator database container: https://github.com/percona/percona-docker/tree/main/postgresql-containers/build/postgres
Thank you for providing the link. I guess I was looking for a repo that just included postgres.
I see now that all database builds are in one place.
Hi Sergey,
Any news on tis? Is it still on your roadmap?
Thanks
Chris
Hello @christopher - it is on the roadmap, but I don’t have any specific ETA for it.
Hello again Sergey,
It’s been another 6 months. Any news on this? Surely we are not the only person who uses custom dictionaries on Postgres and wish to run our instances on Kubernetes?
Thanks
Chris
Hey @christopher,
I think I have a workaround for you through tablespace volumes: Use PostgreSQL tablespaces with Percona Operator for PostgreSQL - Percona Operator for PostgreSQL
This will mount a separate volume. Yes, originally they are designed to be used for tablespaces, but you can use them for anything else.
We have a plan to add completely custom volumes, but this one might work for you already.
Thanks I will give that a try and look forward to hearing more about generic volumes.
Will generic volumes be something that is just for Postgres but will it also appear in your MDB operator?
Is ‘custom volumes’ in development now or something that is on the wish list?
Thanks Again
Chris
@christopher it is in the roadmap, but not in active development right now.
Please let me know if tablespace volumes would work for your use case. In the end, it is just volumes.
Unanswered | Unsolved | Solved
MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright © 2006 - 2024 Percona LLC. All rights reserved.