<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 December 2016 at 22:33, Katherine Cox-Buday <span dir="ltr"><<a href="mailto:katherine.cox-buday@canonical.com" target="_blank">katherine.cox-buday@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Tim Penhey <<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a>> writes:<br>
<br>
> Make sure you also run on LXD with a decent delay to the APT archive.<br>
<br>
</span>Open question: is there any reason we shouldn't expect charm authors to take a hard-right towards charms with snaps embedded as resources? I know one of our long-standing conceptual problems is consistency across units which snaps solves nicely.<br></blockquote><div><br></div><div><a href="https://github.com/stub42/layer-snap">https://github.com/stub42/layer-snap</a> is how I'm expecting things to go. There is already one charm in the ~charmers review queue using it and I'm aware of several more in various stages of development.</div></div><div class="gmail_extra"><br></div><div>More work is needed though. In particular, Juju storage is inaccessible to snaps, because there is no way to reach it from inside the containment.</div><div><br></div><div>(But none of this is a reason to not optimize Juju unit provisioning times, since we will still need an environment setup capable of running the charms so they can install the snaps for some time yet).</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></div>

</div></div>