Rewriting Pulp Operator in Go

[dkliban]

We have started working on a Go implementation of Pulp Operator. The POC is here.

Here is a list of considerations we made before starting this effort:

PROS:

• Better debugging
• Better control of the logs
• Faster deploy and execution ( parallel tasks execution)
• We will be able to add unit tests
• Tests (unit and functional ) can be run in parallel. Golang provides an embedded test package to write unit tests)
  Does go test run unit tests concurrently? - Stack Overflow
• Most of the operators are written in go. Kubernetes is also written in go, which gives a better control of the environment.
• Not really a golang benefit, but if we are willing to go ahead and rewrite the operator, we could take the opportunity to split it into multiple operators following the best practices
  • OperatorHub.io | The registry for Kubernetes Operators
  • OperatorHub.io | The registry for Kubernetes Operators
• Kubernetes community
• based on above points, faster development speed, less burden to maintain

CONS:

• re-write operator from ansible to go (translation from ansible to go is not that painful)
• rewrite/port existing tests
• learn go
• learn the migration process to generate the bundle https://github.com/operator-framework/operator-registry/blob/v1.16.1/docs/design/operator-bundle.md

[quba42]

This may be a dumb question, but what is Pulp operator?

[ipanova]

Generally operators help to simplify deployment, management, and operations of applications in Kubernetes. Pulp operator takes care of Pulp application in clustered containerized deployment, like openshift.
https://docs.pulpproject.org/pulp_operator/

[chadams]

The other pros I can think about for the ansible-operator implementation pulp/hub operator are:

• Maintainability: it is easier to get new developers up an running on the awx-operator, and ansible tasks are generally more readable.
• Consistency: the other 4 operators in AAP and Ansible Cloud Add-ons (the Ansible on Clouds helper bundle) are ansible operators, so it is easy for a developer to go back and forth. Since there is currently a lot of overlap in design, it makes applying the same type of patch to multiple operators easy.

And added con for the Go Operator approach is:

• There are midstream scripts that “downstreamify” the operators, which will likely have to be re-written

[fao89]

@chadams

The other pros I can think about for the ansible-operator implementation pulp/hub operator are:

• Maintainability: it is easier to get new developers up an running on the awx-operator, and ansible tasks are generally more readable.

This may be true for the awx-operator, but I think pulp-operator is more complicated as it handles multiple services (api, content, workers,…), the more roles, the more complex it is to maintain

[chadams]

re: downstream scripts needing to be updated:

• platformify.sh - manifest and csv yaml files should be unchanged when moving to Go Operator, so this will largely stay the same
• render_templates - same here
• downstreamify.sh - this script updates code references in the operator itself, I expect there will be changesd needed here. Let’s work together to identify those changes and make them if we decided to go forward with the Go Operator re-write.

[fao89]

Go based operator on OCP:

Pulp Go Based Operator on Openshift

[jmickeyd]

I may be missing something as I’m still fairly new to pulp, but it doesn’t feel like there is really much logic in the operator at all. Is there is a reason you’re not just using a helm chart? Operators open up a large can of worms in terms of auditability.

[ipanova]

@jmickeyd

it doesn’t feel like there is really much logic in the operator at all

Can you expand on this statement?

@jmickeyd

Is there is a reason you’re not just using a helm chart? Operators open up a large can of worms in terms of auditability.

I believe Helm and Operators have their own usecases when they are used. Charts are good for simple application installation and cluster management, when it comes to customizations, complex and mature cluster management operators are more handy.