Enhance: Refactoring of structure

[victorock]

Better accommodate exporters.

[raelga]

Hello @victorock, thanks for reaching out!

The current structure is tied to the way the OperatorSDK works, you can see the generated scaffold here: https://sdk.operatorframework.io/docs/building-operators/ansible/tutorial/

Can you provide more information regarding your proposal?

[victorock]

@raelga sorry about not clarifying what i meant. I was referring to the ansible content under: roles/prometheusexporter/.

[raelga]

What did you have in mind?

[victorock]

@raelga follow here an example to validate the idea, before going through testing, etc...

I've also integrated some additional content and logic to be able to better handle the lifecycle of the operator itself:

• In a case where something goes wrong during the deployment, and we want to specify external/tasks roles to recover...

• if we want to trigger pre tasks/roles for scenarios like upgrades...

• if we always want to trigger post tasks/external roles helpers...

With this implementation, tasks moved to here, so we avoid accidental changes by users integrating new exporters...

As such, users only care about changing exporters specifications here...

[slopezz]

Thanks for the input @victorock, let us review it carefully as there are many changes, and we will get back to you, but the overall looks good!

[raelga]

@victorock your changes look really good, thanks for the improvements.

I can't think right now, for the current operator, an escenario that pre/post task may come helpful who knows. The rest of the changes, makes the code more clean and extensible.

Feel free to push a pull request so we can do a final review and integrate your changes. :)

[slopezz]

@victorock, as @raelga said, the overall looks really nice, cleaner and easier to integrate a new exporter. Just a few comments/suggestions before opening the pull request:

• Role name should not be renamed from prometheusexporter to prometheus_exporter, this comes from default operator-sdk behaviour, and we prefer not doing so:

  $operator-sdk init --plugins=ansible --domain=3scale.net
  Next: define a resource with:
  $ operator-sdk create api
  $ operator-sdk create api --group monitoring --version v1 --kind PrometheusExporter --generate-role
  $ ll roles/
  total 0
  drwxr-xr-x 9 slopez slopez 200 Dec  3 11:40 prometheusexporter

• PrometheusRules can not be included into the role, they are just examples, it is something that depends totally on each db/host scenario with lots of possible casuistics and values to finetune, details at https://github.com/3scale/prometheus-exporter-operator#prometheusrules.
• Tasks management seems a bit complex with pre/post roles/tasks... taking into account the purpose of the operator to be very simple on its roots, which is to manage very simple applications (exporters) by creating a few standard k8s resources per exporter, (service, deployment, serviceMonitor, GrafanaDashboard). Right now I cannot think about an scenario needing it, but would be nice if you have thought about a possible reasons to have those kinds of tasks :)
• Bear in mind we have updated blackbox exporter dashboard on https://github.com/3scale/prometheus-exporter-operator/pull/16 since you forked the repo :)

[slopezz]

Closing issue, it was resolved on https://github.com/3scale-ops/prometheus-exporter-operator/pull/24 where we applied some operator improvements.