Initial Design Considerations on Opcap

[acmenezes]

Quick sketch on what we thought initially for opcap when this group was yet pretty small.

So there are 3 main components:

1. Cmd - https://github.com/opdev/opcap/tree/main/cmd

On the cmd package level we should keep only the interaction with the user and code that will minimally process input to right after deliver flag options to capabilities that is where the action is happening.

The check command is the one triggering a full operator catalog audit installing operator by operator from a designated catalog.

The upload command will retrieve the data written to files to build reports on the dashboard.

2. Capability - https://github.com/opdev/opcap/tree/main/internal/capability

On the capabilities package we have one simple object called auditor that loads what we called audits or as the object name capAudits on a workqueue to be able to audit one operator as a time. Each capAudit is loaded with input information such as namespace name, operatorGroupData, subscription etc to be able to install an operator.

And also an audit plan that is pretty sketchy at this point in time which the idea is to allow people to enter the list of audits they intend to run and those will be ran against that particular operator being held on the capAudit data.

capAudit works like an object in OO language with it's own methods to deal with the capability tasks.

The capability package would consume the operator package when it needs to talk to all the APIs. Kube api, OLM api etc.

3. Operator - https://github.com/opdev/opcap/tree/main/internal/operator

The operator package is where we've put all the functions that interacts with the cluster running the audits. It's where all the clients are built to talk to their respective APIs and perform the backend actions.

Workflow would look like:

cmd --- > calls --- > capability --- > calls --- > operator

It's nice to avoid importing things up and down at the same time and also avoid passing flags all the way to the bottom of the stack. Ideally operator should hide cluster communication from capability to let us concentrate on the capability work not on cluster detailed implementation and calls.

Other packages such as log, error etc. will come and even upload may gain it's own package if it make sense.

All of those are a pretty high level outline on what we've been working on.

And they are also only initial thoughts or suggestions. We do need people reviewing and being able to change it for better so feel free to post any ideas and allow us to work together on the next steps!

From this discussion we can have enough data to put together an official design for our tool!

Please feel free to chime in!

= ) Happy to have more brain power working together!

[OchiengEd]

The discussion was to have some design document albeit minimal, that could be referenced by both existing and new contributors to the project. It may not need to be prescriptive but give a high-level guide on how the code is today and some thought behind it.