[ANN] charm-tools 1.9.3

[Simon Davy]

On 25 November 2015 at 16:02, Marco Ceppi <marco.ceppi at canonical.com> wrote:
> ## Wheel House for layer dependencies
>
> Going forward we recommend all dependencies for layers and charms be
> packaged in a wheelhouse.txt file. This perform the installation of pypi
> packages on the unit instead of first on the local machine meaning Python
> libraries that require architecture specific builds will do it on the units
> architecture.

If I'm understanding the above correctly, this approach is a blocker for us.

We would not want to install direct from pypi on a production service

 1) pypi packages are not signed (or when they are, pip doesn't verify
the signature)
 2) pypi is an external dependency and thus unreliable (although not
as bad these days)
 3) old versions can disappear from pypi at an authors whim.
 4) installing c packages involves installing a c toolchain on your prod machine

Additionally, our policy (Canonical's, that is), does not allow access
to the internet on production machines, for very good reasons. This is
the default policy in many (probably most) production environments.

Any layer or charm that consumes a layer that uses this new approach
for dependencies would thus be unusable to us :(

It also harms repeatability, and I would not want to use it even if
our access policy allowed access to pypi.

For python charm dependencies, we use system python packages as much
as possible, or if we need any wheels, we ship that wheel in the
charm, and pip install it directly from the there. No external
network, completely repeatable.

Another option is to require/configure a local pypi to pull the
packages from, but  again, an external dependency and spof.

I much prefer what the current tool seems to do, bundle deps as wheels
into a wheels/ dir as part of the charm build process.  Then that
charm is self-contained, and requires no external access, and is more
reliable/repeatable.

> This also provides the added bonus of making `charm layers` a
> much cleaner experience.
>
> Here's an example of side-by-side output of a charm build of the basic layer
> before and after converting to Wheelhouse.
>
> Previous: http://paste.ubuntu.com/13502779/ (53 directories, 402 files)
> Wheelhouse:  http://paste.ubuntu.com/13502779// (3 directories, 21 files)

These are the same link?

But looking at the link, I much prefer that version - everything is
bundled with the charm, as I suggest above.

So, to me, this new approach would be a regression :(

If it was my own charms, fair enough, I could just not use this
approach. But, if the base layers and interface layers I'm trying to
use do this, or the other charms from the store that we use do, then
we cannot use them, which would mean forking charms, which we've done
before and helps no one.

Maybe I've misunderstood, but if the new recommended approach involves
pulling from pypi on the unit at deploy them, then this is a big
problem for us, and I think many others.

I don't know where we are at with the resources work, but maybe that
could have a part to play here?

Thanks

-- 
Simon