On Tue 10 May at 10:19:23 -0400 raysonlo...@gmail.com said:
>
> IMO, the best use case of not using a package manager is when deploying into
> containers -- would you prefer to just drop a static binary of your Go code,
> or
> you would rather install "apt-get" into a container image, and then install
> the
> language runtime via apt-get, and finally your application?? I don't know
> about
> you, but many startup companies like Go as it would give them much faster time
> to react.
I think the thread here diverged and missed some important points about
the development lifecycle.
Go is not particularly unique in the need for projects to maintain
stable repos, insure quality, and deliver reproducible artifacts on
a predictable cadence. It happens that many Go projects aren't doing
that well, but there are reasons and mitigations for that which I'll
come back to at the end.
IMHO containers are about ease of the deployment unit. As somebody who
started with linux early enough to experience the pre-RPM days, containers
aren't all that conceptually different than RPM or DEB if you ignore
the namespacing. Packaging by somebody else is a great convenience,
albeit with tradoffs which need active management. Whether the packaging
is an entire OS image or smaller app you docker pull/run, or a bundling
of {.py files, compiled c, compiled go, etc} and systemd unit files and
such is less important than what comes next...
Deployment to production involves risk management on the packaged product
through testing.
The non-toy containers folks (ie: people who don't just run random stuff
from the internet) use CI for that reason. My impression of production Go
usage is one of thoroughly embracing CI/CD: continually go get literally
whatever is the latest without giving it any real thought or analysis,
automatically build and automatically test it, and then if it passes your
release criteria plunk the binary into your deployment and roll it out to
incrementally broader circles of exposure, with automation able to effect
reverts to prior good if something goes wrong. The specific mechanism
for "plunk" will depend on whether your deployment unit is RPM, DEB,
container or otherwise. And aside from "go get" being an actual Golang
thing, it's also just plain english what ever distro does every time
they compose their OS for all their components whether on a 6mo's cycle
or rolling releases, and the majority of their components are not Go.
Ie: this is not a Go conversation. This is modern quality software
development and managing possibly funky upstream opensource inputs.
A tremendous benefit I see in the OpenStack community is that OpenStack
actually has a robust CI infrastructure continually vetting and
actively gating non-passing code. Go has great test tooling and I've
been surprised to find how much its language patterns encourage you to
write code that is CI friendly. The two mechanisms can be plumbed if
policy does not preclude it.
This implicit CI assumption in the Golang world arguably makes it easier
for folks to play fast and loose. They churn out code, at non-reliable
repository hosts, rarely tag or promote stable release points. Instead
they assume a user who cares will have CI implementing their version of
assuring care. This is an issue distros have to deal with, where some
upstreams are more wobbly than others. While this is a notable weakness
in the golang culture for those of us coming to it as outsiders, it is
one OpenStack's infra and processes are built to manage today and is a
weakness which does not need to come into OpenStack.
Chatting with John in Austin, my primary question was how can we help
enable OpenStack CI for Go code. I read John's point of:
"Further work is needed in the OpenStack community to determine the
best way to manage dependencies, handle deployment artifacts, and
ensure proper gate testing."
as being exactly the right first step down the path to insure potentially
sloppy go deps don't have to be a problem.
--
Tim Pepper -- Linux OS Engineering
Intel Open Source Technology Center
__________________________________________________________________________
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
