Clint, I think it's good to find initial idea to work towards to create stuff like infrastructure (testing and such) around golang, code guidance, standards and so on. It takes first project to create all that stuff and it's good if it's bigger community effort. Next projects could just follow these standards really.
As for Kolla using golang - Kolla uses ansible and k8s today;) Or rather Kolla-ansible and Kolla-k8s uses Kolla. If you want to make Kolla-golang, you can...it just doesn't make any sense really (imho);) On 7 March 2017 at 09:31, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Hayes, Graham's message of 2017-03-07 14:19:02 +0000: >> On 07/03/2017 13:22, Davanum Srinivas wrote: >> > Folks, >> > >> > Anyone interested? https://etherpad.openstack.org/p/go-and-containers >> > >> > Thanks, >> > Dims >> > >> >> The first thing that is required (according to the new guidelines) is >> for there to be a technical reason we need to use go, and cannot use >> python. [0] >> >> This was the major point thrown at designate when we asked for >> permission - if there is now a golang project for the sake of >> a golang project, that would seem at odds with these (brand new) >> requirements. >> >> The only item in the linked etherpad that would fit that requirement >> is the Go Common Lib, which is a requirement for any project who wants >> to use go. >> >> Do we want to allow projects innovate, or do we just want Golang in >> OpenStack now? I honestly cannot follow what is going on in this area. >> > > There's a nasty assumption wrapped in that sentence that isn't quite > fair. We've always wanted projects to innovate, but the choice of common > language was entirely designed to put people in a box that was easier > for operators to consume and debug. > > I don't see an actual real problem statement that takes operators and > users into account in that etherpad*. IMO language bindings is a red > herring, we have REST API's and they're not so bad that they have to > be wrapped in convenience libs *cough*OaktreeShade*cough*. > > I'd really like to see *users* and/or *operators* be the focus of any > efforts around Golang, or Lisp, or anything else we ship. > > Designate felt that the operators were better served by a Golang > transfer daemon (IIRC). Hummingbird was created by Swift operators to > deal with their IO concurrency problems. I _like_ those efforts (now > that I understand them, which was not easy). But the etherpad kind of > reads to me like "let's make Go things because container things".. maybe > somebody can explain it to me like I'm 5? > > > * Kolla is a deployment project, and imo, can do Golang the same way > openstack-ansible does ansible and puppet does puppet. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev