Juju 2.1.0, and Conjure-up, are here!

[Simon Davy]

On Fri, Feb 24, 2017 at 11:14 AM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> On Fri, Feb 24, 2017 at 6:51 PM Mark Shuttleworth <mark at ubuntu.com> wrote:
>
>> On 24/02/17 11:30, Andrew Wilkins wrote:
>>
>> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard <adam.collard at canonical.com>
>> wrote:
>>
>> On Fri, 24 Feb 2017 at 10:07 Adam Israel <adam.israel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170224/3cef8da6/attachment.html>