---------- Forwarded message ---------
From: Camila Macedo <cmacedo@redhat.com>
Date: Tue, Apr 16, 2019 at 6:38 PM
Subject: [MSS Operator] - Database
To: Wei Li <weil@redhat.com>
Cc: mobile-customer-success <mobile-customer-success@redhat.com>, Chris Foley <chfoley@redhat.com>
Hi @Wei
In the trello card[1] we have the following acceptance criteria:
"The MSS dependency on PostgreSQL needs to be handled. Use of the existing PostGreSQL operator is preferable"
Following the analyse made over the adoption of a community operator.
h4. Community Options Operators for PostgreSQL (it has not many options)
* CrunchyData - https://github.com/CrunchyData/postgres-operator
* Zalando - https://github.com/zalando/postgres-operator
h4. What option from Community shows is better? Is the CrunchyData or the Zalando one?
* https://github.com/ IMHO the best option is the CrunchyData /postgres-operator .
PS:
* Better The main reasons are; a better doc
* This one , has more users and contributions, it is in at least into the [ operatorhub.io |https://operatorhub.io/?category=Database] and when the other Zelando is 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 CrunchyData shows more in https: stable / /docs mature than Zelando one . 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. What are the CONS of changing our the MSS operator to use it currently, at least?
* Shows that we will not able to use the RedHat image and we will need to use the CrunchyData image
* The CrunchyData PostgreSQL operator can be deprecated and/or discontinued . It has since is not maintained by us and has NOT a big community and/or many quantity of contributors and users etc..
* We may face some issues and /or limitations as for example, we will be not be able to do some specific setup and/or fix some issue and/or handle it for providing the status info for the RHMI as it is done currently
* The effort required in order to understand how it is working, how to setup it, check if it is working well and will attend all the requirements, as how we can try to make the MSS operator have handle it and or get its status for the RHMI.
* May this adoption can The CrunchyData PostgreSQL has many features which may increase the complexity unnecessarily to keep it maintained.
h4. * Conclusion:
*
* IMHO we should keep still be keeping the current implementation where the database as is a type for now and do not care over of the operator, at least currently for now . Following the main reasons for that.
* The current implementation impl attends all our its needs and is quite simple and easy to keep maintained, changed, replaced, disabled etc..
* Also, the current implementation impl 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 We could re-analyse it in the CrunchyData shows future and spend unnecessary this effort just if we check that will be better and required. It is not showing a priority for now at least. Also, may more options could make be available in the future
@Wei Li,
Please, let us know if you have any objection to keeping it more complex as it was done and if is already required plan some task to change the operator in the next steps.
[1] - [MSS Operator] : https://trello.com/c/oLKC7jRi/11-mss-operator-as-a-developer-i-want-a-mobile-security-service-operator-such-that-the-mobile-security-service-can-be-instantiated
Cheers, |
|
