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 as .
If you check in the documentation provided docs and in the training examples you will see that the team attend over all operators following this subject 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 which I understand that it is doing as it is recommended to get done . The Prometheus has one type/ CR for each thing. See here <https://github.com/coreos/prometheus-operator>.
If you check in the docs and in the examples you will see that all operators following this idea/approach that we are doing here and not just Prometheus which definitely is a great example.
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://github.com/awslabs/aws-service-operator/tree/master/examples
* Etcd is another excellent project to follow an 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}
Also
Besides , if we be good practice and which shows recommended and followed for all regards create a one type/ CR for all each thing I am against to change it will not be a good approach at all for many other reasons as for example:
* We will define well. It is clear that we have the type MSS is intention to remove the project + database, for me conceptual it not make sense DB in the future and use a community operator then following some extra argumentations .
* The way that
As it is now we was implemented/designed:
* We can just not install the type DB and use a community operator if we wish
* The wat that is now we We can easily extract the DB and create a new operator just for it
* if 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.
In order to attend the need and 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 just do the required impl to make 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.
PS.: I understand that RHMI will require the same files which are needed to publish the operator in the https://operatorhub.io/.
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] @chfoley@redhat.com
|
|
