GoogleCloudPlatform / elcarro-oracle-operator

El Carro is a new project that offers a way to run Oracle databases in Kubernetes as a portable, open source, community driven, no vendor lock-in container orchestration system. El Carro provides a powerful declarative API for comprehensive and consistent configuration and deployment as well as for real-time operations and monitoring.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Confusing about platfrom dependency

ITD27M01 opened this issue · 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.