Refactoring of Operator

[buehler]

Refactoring of Operator

[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

[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?

[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 📦🚀