Hi Tal, Thank you for the email and really appreciate your offer to prove training material on golang.
Original K8S discussions started with treating K8S as VIM. But that is no longer true. Current K8S plugin leverages all features supported by K8S deployment. On the technical help on K8S plugin, we will certainly like to get your advice and let us talk on COE weekly calls. Also, I will be in Beijing. Let us touch base. Thanks Srini Sent from my iPhone > On Jun 15, 2018, at 18:28, Tal Liron <[email protected]> wrote: > > 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 > [email protected] > https://lists.onap.org/mailman/listinfo/onap-discuss _______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
