On 24/02/17 11:30, Andrew Wilkins wrote: > On Fri, Feb 24, 2017 at 6:15 PM Adam Collard > <adam.coll...@canonical.com <mailto:adam.coll...@canonical.com>> wrote: > > On Fri, 24 Feb 2017 at 10:07 Adam Israel > <adam.isr...@canonical.com <mailto:adam.isr...@canonical.com>> wrote: > > Thanks for calling this out, Simon! We should be shouting this > from the rooftops and celebrating in the streets. > > > Only if you also wave a big WARNING banner! > > I can definitely see value in pre-installing a bunch of things in > your LXD images as a way of speeding up the development/testing > cycle, but doing so might give you false confidence in your charm. > It will become much easier to forget to list a package that you > need installing, or to ensure that you have the correct access > (PPA credentials, or proxy details etc.) and having your charm > gracefully handle when those are missing. > > Juju promises charms encoding operations that can work across > multiple cloud providers, bare metal and containers please keep > that in mind :) > > > Indeed, and this is the reason why it wasn't called out. We probably > should document it for power-users/charmers, but in general I wouldn't > go encouraging its use. Optimising for LXD is great for repeat > deploys, but it wouldn't be great if that leads to less attention to > quality on the rest of the providers. > > Anyway, I'm glad it's helping make charmers' lives easier!
We should call this out loudly because it helps people making charms. Those people are plenty smart enough to debug a failure if they forget a dependency which was preinstalled in their dev images. Don't HIDE something that helps developers for fear of those developers making mistakes, TEACH them to put CI or other out-of-band tests in place anyway that will catch that every time. Mark
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
