You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now, let's say OAM-ROS, is a "translator" between cloud resource Workloads to ROS stack. This significantly lower the bar of provision and consuming of cloud resources in Kubernetes while have some remaining issues unsolved:
Modeling of cloud resources, i.e. higher level abstraction instead of raw ROS objects. Similar concepts exist in Google's Cloud Config.
"Just work" cloud resource consuming workflow, users expect a more uniformed way like Service Binding Operator etc to handle the cloud resource exporting and consuming.
"Just work" data modeling for ROS stack. We need to revisit and design a better solution (for example, an Operator similar to AWS Service Operator) for ROS.
For now, let's say OAM-ROS, is a "translator" between cloud resource Workloads to ROS stack. This significantly lower the bar of provision and consuming of cloud resources in Kubernetes while have some remaining issues unsolved:
All these issues above apply to Terraform provider as well, xref: https://github.com/kubeform/kubeform
The goal is "Better experience for allowing Kubernetes to provision and consume cloud resources with OAM" as the title said.
The text was updated successfully, but these errors were encountered: