<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 1 December 2016 at 13:53, Marco Ceppi <span dir="ltr"><<a href="mailto:marco.ceppi@canonical.com" target="_blank">marco.ceppi@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Dec 1, 2016 at 5:00 AM Adam Collard <<a href="mailto:adam.collard@canonical.com" target="_blank">adam.collard@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_4487595449148172442gmail_msg"><div class="gmail_quote m_4487595449148172442gmail_msg"><div dir="ltr" class="m_4487595449148172442gmail_msg">On Thu, 1 Dec 2016 at 04:02 Nate Finch <<a href="mailto:nate.finch@canonical.com" class="m_4487595449148172442gmail_msg" target="_blank">nate.finch@canonical.com</a>> wrote:<br class="m_4487595449148172442gmail_msg"></div><blockquote class="gmail_quote m_4487595449148172442gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_4487595449148172442gmail_msg">On IRC, someone was lamenting the fact that the Ubuntu charm takes longer to deploy now, because it has been updated to exercise more of Juju's features.  My response was - just make a minimal charm, it's easy.  And then of course, I had to figure out how minimal you can get.  Here it is:<div class="m_4487595449148172442gmail_msg"><br class="m_4487595449148172442gmail_msg"></div><div class="m_4487595449148172442gmail_msg">It's just a directory with a metadata.yaml in it with these contents:<div class="m_4487595449148172442gmail_msg"><br class="m_4487595449148172442gmail_msg"></div><div class="m_4487595449148172442gmail_msg"><div class="m_4487595449148172442gmail_msg"><font class="m_4487595449148172442gmail_msg" face="monospace">name: min</font></div><div class="m_4487595449148172442gmail_msg"><font class="m_4487595449148172442gmail_msg" face="monospace">summary: nope</font></div><div class="m_4487595449148172442gmail_msg"><font class="m_4487595449148172442gmail_msg" face="monospace">description: nope</font></div><div class="m_4487595449148172442gmail_msg"><font class="m_4487595449148172442gmail_msg" face="monospace">series:</font></div><div class="m_4487595449148172442gmail_msg"><font class="m_4487595449148172442gmail_msg" face="monospace">  - xenial</font></div></div><div class="m_4487595449148172442gmail_msg"><font class="m_4487595449148172442gmail_msg" face="monospace"><br class="m_4487595449148172442gmail_msg"></font></div><div class="m_4487595449148172442gmail_msg"><span style="line-height:18px" class="m_4487595449148172442gmail_msg">(obviously you can set the series to whatever you want)</span></div><div class="m_4487595449148172442gmail_msg"><span style="line-height:18px" class="m_4487595449148172442gmail_msg">No other files or directories are needed.</span></div></div></div></blockquote></div></div><div dir="ltr" class="m_4487595449148172442gmail_msg"><div class="gmail_quote m_4487595449148172442gmail_msg"><div class="m_4487595449148172442gmail_msg"><br class="m_4487595449148172442gmail_msg">This is neat, but doesn't detract from the bloat in the ubuntu charm.<br class="m_4487595449148172442gmail_msg"></div></div></div></blockquote><div><br></div></span><div>I'm happy to work though changes to the Ubuntu charm to decrease "bloat".</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_4487595449148172442gmail_msg"><div class="gmail_quote m_4487595449148172442gmail_msg"><div class="m_4487595449148172442gmail_msg">IMHO
 the bloat in the ubuntu charm isn't from support for Juju features, but
 the switch to reactive plus conflicts in layer-base wanting to a) 
support lots of toolchains to allow layers above it to be slimmer and b)
 be a suitable base for "just deploy me" ubuntu.</div></div></div></blockquote><div><br></div></span><div>But it is to support the reactive framework, where we utilize newer Juju features, like status and application-version to make the charm rich despite it's minimal goal set.</div></div></div></blockquote><div><br></div><div>Yeah, and I think this is a good thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Honestly, a handful of cached wheelhouses and some apt packages don't strike me as bloat</div></div></div></blockquote><div><br></div><div>No it's not per-se. However I think this highlights a more general issue with the current implementation of the reactive stack. It's not only the ubuntu charm that has slowed done, it's any reactive-based charm, because the steps required to "setup" reactive take longer than they used to.</div><div><br></div><div>I see a couple of (possibly alternative) ways to improve the situation:</div><div><br></div><div>1) Make sure the dependencies of the base reactive layer are packaged, that should be much faster than pip install, and fall back to pip only for what's not there (i.e. dependencies added by the consumers of the base layer). Also, package the base layer itself.</div><div><br></div><div>2) Add support for images, so when you deploy some vanilla charm there's an associated "pre-built" image that will be very fast. I guess this is in the juju road map anyways.</div><div><br></div><div>We always need to keep in mind that this experience will be compared with things like Kubernetes and Docker, and speed-y deployments really unlock velocity when iterating on charm development (think for instance running integration tests).</div><div><br></div></div></div></div>