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.