h4. Community Options
* https://github.com/CrunchyData/postgres-operator
* https://github.com/zalando/postgres-operator
h4. What option from Community shows better?
* https://github.com/CrunchyData/postgres-operator
PS:
* Better doc
* This one is in the [operatorhub.io|https://operatorhub.io/?category=Database] and the other not
h4. What image and version we are using currently in the specs of the MSSDB CR?
* The imaged used in this project is from Red Hat. See more in https://docs.okd.io/latest/using_images/db_images/postgresql.html
* image: "centos/PostgreSQL-96-centos7"
PS.: The MSS project was developed and tested so far with PostgreSQL 9.6
h4. Pros and Cons Following the cons of doing this change the current implementation for it currently in POV.
||PROS (+)||CONS (-) ||
|Has a bkp feature implemented| * It has many features and we need to understand how to set up , configure and use |
| * It can be deprecated and/or discontinued. PS.: It has not a big community and or many contributors so far anyway. |Show that we will need to use is using their images and not the RedHat ones, however, shows that their image is based on centos |
|Show * it can be deprecated and/or discontinued. It has good documentation| not a big community and/or many contributors and users
* We may face some issues and limitations as for example, we will be not able to do some specific setup and or fix some issue and/or have handle it for providing the status for the RHMI as we have it is done currently |
|It can be deprecated and/or discontinued | * We need to spend an effort to try to make it work as a dependency and handled handle the database created by the operator for 3.11 mini shift and in OCP 4 |
| | May it will increase the complexity unnecessarily |
| | * We need to test and check it in order to ensure that all requirements will be attended for with and that it will actually is working well as we expected |
* The usage of this operator may increase the complexity unnecessarily.
h4. Conclusion:
IMHO we should keep the database as a type for now and do not care over at least currently. Following the reasons
* The current implementation attends all our needs and is quite simple and easy to keep maintained, changed, replaced, disabled etc..
* Also, the current implementation allows we easily, without any code change, make the MSS use another database and/or disabled this type, change the image and/or its versions as the parameters and values used
* IMHO add now the CrunchyData shows spend unnecessary effort and could make it more complex
|
|
