Comment 40 for bug 1267393

Revision history for this message
Mark Ramm (mark-ramm) wrote : Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang

@martin

"Traditionally the Tech board has nacked everything in main which pulls code from third-party sources, i. e. "installer packages". Packages in main must not enable any third-party PPA, pull code or binaries from an upstream site and run it, and so on."

I think a key point here is that the juju package does not generally install or pull down binaries from anywhere to your machine. It does instruct the cloud installation of a server to use a specific ubuntu image from simplestreams and a specific jujud binary (also from simplestreams) on the remote host.

"(Caveat: I have no idea what simplestreams is and how it works; the description on https://launchpad.net/simplestreams isn't very enlightening, but it sounds like you want to use it as a kind of package distribution system not unlike pip?)"

Simplestreams is a tool the server team created to help us catalog, sign, and distribute "cloud images" which are Ubuntu OS images, which can be generic, or customized to run on a specific cloud. The server that gets launched in the cloud when you use "juju bootstrap" picks a cloud image from simplestreams, verifies it's cryptographic signature, and starts a machine using it, we then grab the appropriate juju binary from simplestreams and install it (again on the remote server). So, juju isn't creating a need to trust simplestreams for the juju binary -- it already must be trusted for cloud images. And we're not creating our own system of packaging for jujud binaries, we're just piggiybacking on the way we distribute Ubuntu images in a cloud context.

There is a small caveat: juju does have a "local provider" feature that sets up lxc containers and runs the jujud binary there. The local provider is designed to simulate a full cloud environment in containers on your local system, and when you do that we do the same thing as I mentioned in doing on the remote side above, we use simplestreams to select the right cloud image, and juju tools binary. That is the only case in which the juju client would download a binary from simplestreams and run it locally, and in that case it is downloading both the cloud image, and the juju binary. So, fixing the juju binary doesn't fix that -- we're still grabbing a binary blob from simplestreams and executing it locally -- the cloud image itself.