{{ message }}
Repository navigation
Support hybrid operators #670
Description
EDIT(@estroz): this issue originally addressed a bug where users could create apis, controllers, and k8s deepcopy code in non-Go projects. Since significant discussion related to hybrid operators is present here, I changed the title and am keeping this issue open to further track hybrid operator discussion. #672 fixed the original bug.
Original issue text:
The following SDK commands are only relevant to a Go type project and should not run in another project type like Ansible(or Helm in the future).
operator-sdk add api ...operator-sdk add controller ...operator-sdk generate k8s
Activity
hasbro17 commentedon Oct 30, 2018
We need to consider the use case of transitioning from a pure Ansible type project to a hybrid or Go type project before we restrict these commands from running in an ansible type project.
shawn-hurley commentedon Oct 31, 2018
I was thinking that the steps for transition are:
cmd/manager/main.goon disk (this will need to be the correct main.go though maybe there is enough overlap between helm and ansible here that we can make this really easy and only 1 file?).All of these are steps I could document today and we would have a transition path, before or after
operator-sdk add apiis called. Maybe it makes sense that we have to do these steps before you can call these? I am torn here because I could see myself creating the API and then doing the main file bits etc..., but on another hand sometimes taking away options just leads to fewer bugs.I think either way the above commands must be in the gopath is that correct?
joelanford commentedon Oct 31, 2018
@shawn-hurley I think the only differences would be loading the watches.yaml file and calling
Add()with the correct controller. If those aren't the only differences, I would think we could get there.Also, do we need to consider transitions between or hybrid combinations of arbitrary types (e.g. Ansible to Helm, or hybrid Ansible/Helm)?
I think this discussion raises the question of what the strategy for the CLI design should be. The current design holds up well when there's only one operator type, but now that we'll have three, each adding new subcommands and/or implementing existing subcommands differently, some issues arise:
--typeis required for hybrid operators?Is it possible to invert the precedence of operator type and subcommand in the CLI so that the operator type drives what subcommands are available and makes the subcommand execution explicit?
estroz commentedon Nov 1, 2018
A combination of good transition/hybrid documentation and strict checks/plenty of warnings on CLI usage should be enough.
Instead of thinking of all the ways a user can combine operator types, we should be opinionated about how they should be combined, and to what extent combination is allowable, if at all. For example, what parts of an Ansible project can be customized with Go, and what cannot?
If we want to allow hybrid projects, we need to reconsider how
OperatorTypeis used since type checks are currently exclusive. I suggest we implement a bitfield.[-]SDK commands for Go operators should only run in Go type projects[/-][+]Support hybrid operators[/+]hasbro17 commentedon Jan 18, 2019
ref: #860
With #887 and #897 the operator-sdk now has a
migratecommand to transition Helm and Ansible operator projects to hybrid projects.@joelanford and @mhrivnak I don't think we have docs or extra sections in the ansible and helm user-guides showing an example of migrating to a hybrid project. We have the CLI reference but I think an example would be beneficial.
Is there anything else that we would need with regards to hybrid operators before we close out this issue? We can follow up on the docs in separate issues.
mhrivnak commentedon Jan 18, 2019
On the ansible side (haven't looked closely at the helm side, but might be similar) we have a working
migratecommand that might be useful. But we have not put any thought yet into specifically how we'll enable users to add their own logic. We don't have a good story yet for: "ok, I have amain.gofile. What now?"What we do have lays the groundwork for improving the experience, and it was important to do in concert with the other refactoring around where and how we're building the ansible/helm operator binary and base image. But it might not yet be useful enough to make noise about, which is why I haven't rushed to write docs about it.
The next step would be to spend a little time designing what we want to expose in
main.gothat would be useful to a user who wants to add some go code to their ansible or helm operator. How that relates to this github issue depends on how you prefer to track it. I'm happy if you want to close this as done and follow up with a separate design effort, o if yo'd rather keep this open until it's fully baked.hasbro17 commentedon Jan 19, 2019
Agreed. We should spend some time on the overall user story around hybrid operators.
I'll keep this issue open until we have something more concrete on that front.
9 remaining items
openshift-bot commentedon Oct 19, 2019
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting
/remove-lifecycle rotten.Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting
/lifecycle frozen.If this issue is safe to close now please do so with
/close./lifecycle rotten
/remove-lifecycle stale
hasbro17 commentedon Oct 20, 2019
/lifecycle frozen
huizengaJoe commentedon Mar 19, 2020
@devnulled your comment
#670 (comment)
really resonates, I know its an old post but wondering if you had pursued your hybrid approach and might have some more insight
devnulled commentedon Apr 28, 2020
@huizengaJoe I'm no longer working at the company where I was working on that solution, and it's been some time since I was there. Something I will likely end-up digging back into within the next year or so, I think.
varshaprasad96 commentedon Jul 31, 2023
Hybrid operators are being supported currently with SDK. The current hybrid model involves both Go and Helm APIs to be scaffolded together: https://github.com/operator-framework/helm-operator-plugins/tree/main. Closing this issue for now. If there is any follow up needed, we can pick it up later.