Hi [~lfitzgerald],
The App is one CR as the Database is another. Note that each CR means one type of resource. This project was developed following exactly the instructions of the Getting Started and the operator-framework doc.
If you check in the docs and in the examples you will see that all operators following this idea/approach which shows indeed what is recommended to get done as a good practice anyway.
{panel:title=Examples}
Note that the way that it is now with one type for the DB and another for the APP we are following the same approach of Prometheus for example. The Prometheus has one type/ CR for each thing. See here <https://github.com/coreos/prometheus-operator>.
*This one has the service and database as us:*
* https://operatorhub.io/operator/alpha/aqua-operator.v0.0.1 ( AquaDatabase CR, AquaServer CR, AquaGateway CR and etc )
* https://github.com/aquasecurity/aqua-operator/tree/master/deploy/crds
*This one is from AWS in HELM and has one CR for each thing as well ( DynamoDB, ECRRepository and etc .. )*
* https://operatorhub.io/operator/alpha/aws-service-operator.v0.0.1
* https://github.com/awslabs/aws-service-operator/tree/master/examples
*Etcd is an excellent project to follow as example and is doing as us one CR for each thing ( etcd Cluster, etcd Backup, etcd Restore )*
* https://github.com/coreos/etcd-operator/tree/master/example
* https://operatorhub.io/operator/clusterwide-alpha/etcdoperator.v0.9.4-clusterwide
Please, feel free to check the operators available in https://operatorhub.io/ to validate this approach as its documents.
{panel}
{panel:title=Specific reasons to keep the both CRs regards our bussiness}
Besides, be good practice and which shows recommended and followed for all regards create one type/CR for each thing I am against to change it for other reasons as well. It is clear that we have the intention to remove the DB in the future and use a community operator then following some extra argumentations.
As it was implemented/designed:
* We can just not install the type DB and use a community operator if we wish
* We can easily extract the DB and create a new operator just for it
* If we would like to remove the DB from the project then it is very very easy since is very clear what should be removed or not when we have a specific type for each thing.
{panel}
{panel:title=What was done and can be done over usability? }
In order to attend the need to make the things easier for the users and us we impl the make commands. By the make commands you can, for example, run `make create-all` and it will create the namespace, apply the CRs, the roles and the service account and etc ...
Also, we can put our project available in the operatorHub as well which will allow the users to install our product by click and a beautiful interface. See the PR: <https://github.com/aerogear/mobile-security-service-operator/pull/15> It is already doing it, just need some changes/fixes to get done.
{panel}
PS.: I understand that RHMI will require the same files which are needed to publish the operator in the https://operatorhub.io/ and that [~weili] already agreed with it as well.
I hope that this info clarifies the reasons for it got done in this way and allow us to close this task.
c/c [~dffrench] [~weili] [~peter.braun] |
|
