nolar
Is kopf operator is not a production ready assest ??
Keywords
No response
Problem
Hi, Can you please confirm that is it advisable to use this faramework to write a production ready code ??
Because there is noticed a warning as been added recently as per below screenshot:
So it is better to use operator sdk framework rather than this ?
It was a bad joke and a bad idea from my side to put this feedback into the docs.
As for the usage, it is up to you to decide. This framework, so as Python in general, are quite unusual for the Go-based world of Kubenetes. There are trade-offs: it might be convenient in the beginning, but it will be more difficult to migrate when/if you move to Go.
As a rule of thumb, I recommend that teams choose the languages & frameworks they are the most familiar with, and experienced in — unless they already know the specific requirements of what they are doing and which highly specialised tools are most suited for that. In most cases, maintainability beats performance cost-wise.
If its a bad joke, then can you please remove that from your documenation ?
As it is giving the bad expression on the usage of this framework.
And do you think it is okay to continue with this framework if I want to stay in the python and there is no plan to migrate to go.
Removed. Thanks for the feedback. (UPD: But the build has failed due to missing/yanked dependencies; I will fix it a bit later.)
As for the usage, the answer is highly dependent on your context, pros & cons in your situation — it is up to you to decide. Sorry, I do not provide consultancy on software engineering for 3rd parties at the moment, so I cannot evaluate this decision for you.
@nolar Thanks for removing the warning (have a new tool in my toolbox now), but I found this discussion way too late. We ended up going with a different solution, and spent time porting the code from kopf based on that joke. No big deal.
