On Fri, Feb 24, 2017 at 11:14 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote:
> On Fri, Feb 24, 2017 at 6:51 PM Mark Shuttleworth <m...@ubuntu.com> wrote: > >> On 24/02/17 11:30, Andrew Wilkins wrote: >> >> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard <adam.coll...@canonical.com> >> wrote: >> >> On Fri, 24 Feb 2017 at 10:07 Adam Israel <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. >> > > I was thinking about deployment times more than anything else. If you > don't feel your user's pain, you're less likely to make it go away. But > anyway, that can be fixed with automation as well (CI, as you say below). > I agree there is a risk here. In my specific case, I judge the benefits to outweigh the costs, by quite some margin. But that judgment is specific to my use case, where layer-basic and IS' basenode add significant package churn on every node[1] (increasing the benefit), and we have a full mojo-based CI pipeline for bundle changes (lowering the cost). On a different tack all together, I think that reducing iteration time for charm development is a *massive* win for users. Faster iterations mean faster feature development and bug fixes, and more comprehensive testing (as it costs less). I would estimate that iteration improvement would outweigh the increased risk from a missing pre-installed package, but YMMV. [1] ok, so not every charm we deploy is layer based, but they are heading that way... 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. >> > > FWIW, it wasn't intentionally hidden to start with, it was just missed. I > made the changes primarily to support an external user who wanted to demo > CentOS charms on LXD; the change also enabled custom images in general, and > also slightly improved container startup time. Three birds, one stone; only > one bird-hitting was reported ;) > This is hugely appreciated. I reckon 95% of my deployments in the average week are to lxd, so improvements to the lxd provider affect my velocity considerably. Thanks -- Simon
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju