Refactoring of Operator

[buehler]

In collaboration with @ocdi;
Refactoring of the logic how the operator is used.

It should be more like a "normal" addon to the generic host of asp.net core and introduce it's complexity there.
Therefore we introduce some breaking changes and make a major version bump.

Topics to tackle:

• Refactor the operator startup logic to be an extension method of the generic host
• Return a IOperatorBuilder from services.AddKubernetesOperator that can perform more finetuning
• Add proper code linting
• Add proper (more or less) testing tools (maybe a WebApplicationFactory class for the operator? in context of xUnit)
• Finetune the IOperatorBuilder methods (add resource controller, add finalizer, add ...)
• Refactor finalizer appending -> it would be cool to have a "finalizer register" when one can add a finalizer to a resource instead of having to fetch the finalizer from DI and add a myriad of generic information to the method
• Refactor / overlook all the generics. some types cannot be infered and it would be nice to have less generic type arguments (like the add resource controller method)

anything else? :-)

[buehler]

Code linting is inserted to have some kind of code style #46

[ocdi]

I started laying out IOperatorBuilder and did the obvious one AddController.

To handle finalizers I was thinking of making the AddController method look something like this, that way you can chain the finalizers and keep the context of the controller.

public OperatorBuilder AddController<T>(Action<ControllerBuilder<T>>? builder = null)
    where T : class, IResourceController
{
    _services.AddResourceController<T>();
    if (builder != null)
    {
        var cb = new ControllerBuilder<T>();
        builder(cb);
    }

    return this;
}

public class ControllerBuilder<T>
{
    public ControllerBuilder<T> Finalizer<TFin>()
    {
        return this;
    }
}

I'm not sure what to do in the Finalizer method yet though. It would be nice if we could register this as a dependency specifically to be inserted to T for the IResourceController but I don't know how to do that generically.

If we do go down this road, the ControllerBuilder should probably have a reference to the OperatorBuilder and we should expose a Services property so we can do additional DI registrations.

[buehler]

Mhmm. Yea I know what you mean. I've got an idea about this.

[buehler]

One big question remains on how we can add the "commands" that I added for convenience to install / uninstall crds and generate stuff?

[ocdi]

I think most of the checklist is now done! The only possible thing I would suggest is the removal of the test code from KubeOps. I guess it probably comes down to is the test code making it easier for your unit tests in the project or for consumers of the library to make unit tests. My suggested approach would be creating a KubeOps.Testing package that can contain the test code.

What are your thoughts on that?

[buehler]

Nice :-)
Yes I thought of that (the testing issue) when I first created the project, but back then I was more like "meh...". Now It makes absolute sense. I accidently closed your pull request when I merged my refactoring branch. I'm gonna tackle the issue right away. The goal could be to have a release today or tomorrow :-)

[buehler]

Since the two of us have quite a difference in time between Australia and Switzerland, I took the liberty of updating the readme and splitting out the testing package myself

[github-actions]

🎉 This issue has been resolved in version 2.0.0 🎉

The release is available on:

• GitHub release
• v2.0.0

Your semantic-release bot 📦🚀