Comment 24 for bug 1267393

@adam

> I think you'd agree that the obvious and simple usecase isn't "I
> installed juju-core on my Ubuntu desktop so I can rollout charms on OSX
> and Solaris".

Don't forget it will not support: old Ubuntu versions, Arm64, or power,
other versions of Linux, Windows, or anything but the series that the
package belongs to. I think we can all agree that a Trusty desktop and
Precise database server is a pretty common situation, and the combination
of all the things that won't work is definitely common enough to make it a
real issue.

> So, if we can build them with the packages, what's stopping us from
> having a package that includes the bits, and even depends on the right
> things to set up a simplestreams provider that people can use on their
> closed networks?

We certainly *can* do that. I have no objection to it in principle.

But, before we go down the path of "what's stopping us," Let's take a look
at the situation now:

The obvious and simple use case is that I'm using Amazon, or Azure, Joyent,
or HP Cloud. In those cases the tools are pre-published to a cloud local
"bucket" and it would slow things down and create pain for the user if
binaries had to be copied over from the local disk into the cloud. To top
it off, the jujud binary isn't used locally (except of course when you are
deploying charms locally) so having it on local disk is just waste in those
cases.

Furthermore, we need tools to be published to all the major clouds *before*
the matching client lands in Ubuntu, because a new clients can require
matching tools to bootstrap a new environment. (We do however maintain and
stringently test backwards compatibility with already bootstrapped
environments).

We *have to* publish tools in simplestreams. We *can* put them in the
package too -- as a limited and broken fallback mechanism that doesn't
support multiple archs, doesn't support multiple series, doesn't support
multiple OS's.

My question is, if I take folks away from current projects, and have them
update the packaging so that the tools you mention are there, what exactly
does that buy us? I'm happy to do it, but I would like to know why exactly
you want it, and what benifit it provides to our users.

Another idea we had was to build tools for all supported series, OS's and
arch's and put them in a single package, with the bits you need to push
things up in a simplestreams location for your closed network. But our
belief was that such a package would never be supported, particularly since
the binaries in question won't be run on the local machine anyway, and are
likely to just be a waste of disk space.

We've done a lot of thinking on this, and we have *tried* to figure out how
to use ubuntu packages to distribute tools -- and fundamentally
simplestreams is a better fit for the needs of a multi-os, multi-arch,
multi-series orchestration tool. And we already force users to trust
simplestreams to get Ubuntu images, so we're not adding *another*
mechanism, just re-using one that already exists and is quite widely used.

--Mark

On Wed, Mar 26, 2014 at 5:54 PM, Adam Conrad <adconrad@0c3.net> wrote:

> @Mark
>
> So, if we can build them with the packages, what's stopping us from
> having a package that includes the bits, and even depends on the right
> things to set up a simplestreams provider that people can use on their
> closed networks? Sure, that won't have ALL the binaries for all
> supported platforms available, without a source to grab those from, but
> it would keep it self-contained for the simple use-case.
>
> I think you'd agree that the obvious and simple usecase isn't "I
> installed juju-core on my Ubuntu desktop so I can rollout charms on OSX
> and Solaris".
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1267393
>
> Title:
> [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions
>