Possible use case for bundle-lib and operator framework?

[maleck13]

I have been thinking about the bundle lib and the operator framework / pattern. This is a little half baked and may not have legs but I am going to throw it out there as an idea or use for the bundle-lib and hopefully get some thoughts and feedback

If operations teams don't want to write Golang or already have a bunch of cluster management scripts / playbooks for managing services etc perhaps there is something that could be done with making an operator that executes Bundles based on a Operation resource type.
The idea would be that the team would containerize these scripts and put them in container registry exactly as with APBs. Then they would define a resource that would specify when that bundle should be executed (requires some kind of DSL).
Example:

• Monitor the PV resource and if running out provision more storage and set up more PVs

There are sure to be a hundred more (effectively anything you might create an operator for) . So effectively this is a generic operator leveraging the bundle-lib and some form of DSL to automate the operations tasks without needing to write a full operator in a similar fashion to how the automation broker allows you to leverage a service broker without needing to write your own.

@rthallisey @jmrodri @eriknelson interested in any feedback on this concept you might have

[LorbusChris]

I think leveraging the operator framework makes sense!
A future use case that I can think of is using an operator to automatically update (or even provision) Service Bundles.

[rthallisey]

@maleck13 great suggestion. The community has had some ideas in this area, but they pre dated bundle-lib. Now with bundle-lib it make it easier to implemented an operator pattern.

One candidate for the operator pattern is the registry adaptor. Each adaptor is an operator that periodically queries the registry and updates the bundle CRD.

If operations teams don't want to write Golang or already have a bunch of cluster management scripts / playbooks for managing services etc perhaps there is something that could be done with making an operator that executes Bundles based on a Operation resource type.
The idea would be that the team would containerize these scripts and put them in container registry exactly as with APBs. Then they would define a resource that would specify when that bundle should be >executed (requires some kind of DSL).
Example:

Monitor the PV resource and if running out provision more storage and set up more PVs

A second operator thought of was called a "vessel". It's very similar to what you outlined. The broker would launch a vessel that monitors a resource. When the vessel identifies a certain state it would POST to the catalog the apb + params it wants executed. So the operator in this case is a thin monitoring agent written in Go + sbcli (NEW asb tool in Go). Then the folks that have all the operation management scripts and playbooks would create a bundle.

There are sure to be a hundred more (effectively anything you might create an operator for) . So effectively this is a generic operator leveraging the bundle-lib and some form of DSL to automate the operations tasks without needing to write a full operator in a similar fashion to how the automation broker allows you to leverage a service broker without needing to write your own.

+1

[shawn-hurley]

We have started working on something called automation operator which I think covers this bug.