Hi everyone, I've been following the conversation silently for a while, but it might be time to jump in --
I am working on a training tutorial for Go, for my own team, and would be happy to pass it on to anyone involved in ONAP. It's meant for veterans like you who just need some pointers for the main stumbling blocks of this productive language. In Beijing next week I will be giving two talks related to the technologies discussed. In one, I will present a tool to deploy directly to Kubernetes from TOSCA models. In the second, I will introduce "operators" as a way to create domain-specific clustering in Kubernetes, which I think we'll be seeing more and more of in the Kubernetes space. All of this work is in Go. (For what it's worth -- despite finding Go extremely useful, I'm actually not sure that Go is the best choice specifically for writing operators. I'll discuss the issue in my talk.) I can probably contribute more significantly to the COE project, but I must be honest and say that I have serious concerns about its overall approach. I am not convinced that it's fruitful to treat Kubernetes as a VIM. This is especially apparent as we see more and more truly cloud-native services that manage their own lifecycles. Not only do they know best, but the custom code to self-manage (operators) is embedded within the service. (That's why it's "cloud native".) There's just so much more to Kubernetes then deploying replicated pods. As a small example, on topic: I can't see having the ObjectMeta.Name as having meaning externally in all but the most trivial Kubernetes applications. I see that the COE project is moving forward confidently, so I hope we can talk more and perhaps find ways in which I can work with you constructively. I'm sure that despite disagreement we can find some overlap in our goals and help make ONAP better.
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
