Confusing about platfrom dependency
ITD27M01 opened this issue · 2 comments
Describe the bug
The true Kubernetes way is to avoid any dependencies on the underlying platform and allow the application to run the same way on any K8s cluster installation. Also, the nature of the app itself doesn't matter should it be stateful or stateless.
Nowadays, the cloud provider's code is moved out of the tree in the separated external cloud provider's repos. Kubernetes allows dealing with abstract things like Ingress, StorageClass, LoadBalancer services, etc. Such things hide the underlying platform from the applications and allow them to run on any Kubernetes installation, be it Minikube, GCP, or any other way to run k8s. The logic to provision such abstract things is delegated to the appropriate cloud provider binary. This binary knows better what to do to provide a service.
As I see, in the v0.1.0-alpha version there is a small amount of platform depended code and in most cases it is useless and it is a good time to redesign the Elcarro operator to make it more interesting for the community.
Expected behavior
Cloud agnostic way to run ELCarro Oracle Operator.
Additional context
Cloud Providers in Kubernetes
Hi Igor,
Thanks for your comment. Apologies for the delayed reply. You're right, Kubernetes operators should avoid using platform specific code. This is something we've kept in mind as we've made improvements to El Carro and our end goal is for El Carro to not require users to specify platform specific configuration. We're looking for volunteers who want to contribute changes to make that happen given that the El Carro dev team is currently hard at work developing other features. For starters, would you be willing to open a series of GitHub issues to help identify the key areas of the codebase that need to be updated to reduce dependency on platform code? Thanks again!
Ash
Closing this due to inactivity.