We would still need a way to declare what should be installed ahead of time, so a list of packages somewhere in the charm would be required -- which would look very similar to what Kapil proposed for the "build hook."<div>
<br></div><div>If we have that stuff available in the charm, it's just up to what code does the package installs. </div><div> </div><div>If we use cloud-init we'd have to:</div><div><ul><li>special case dependency installs when we use force-machine to do container-less co-location</li>
<li>make both the provisioner aware of what unit will be deployed onto what machine (right now this is all nicely contained in the unit agent) </li><li>special case it if we end up supporting other host OS's that may not have cloud-init </li>
</ul><div>So, I'm not not convinced of the value of having cloud init do this work rather than a juju agent.   </div><div><br></div><div>Not to mention the fact that we still haven't even decided if this is worth putting on the priority list ;) </div>
<div><br></div><div>--Mark Ramm<br><div><br><div class="gmail_quote">On Tue, May 28, 2013 at 2:10 PM, Adam Gandelman <span dir="ltr"><<a href="mailto:adamg@canonical.com" target="_blank">adamg@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 class="im">On 05/26/2013 08:02 AM, Mark Canonical Ramm-Christensen wrote:<br>
> There are multiple inter-related issues that are being discussed here:<br>
><br>
> * making it easier to write charms in Ruby or PHP when those languages<br>
> are not available in the cloud image by default.<br>
><br>
> * making it easier to support charms on private clouds that block<br>
> outgoing network access (egress filtering)<br>
><br>
<br>
</div>Just curious.. Why hasn't cloud-init been leveraged to address these two<br>
points?  Seems it would be easy to expand potential charm metadata<br>
(additional packages, pre-install requirements, etc) or environment<br>
config (apt_proxy) into additional cloud-config that gets appended to<br>
what juju already generates.  Or has it been a design decision to avoid<br>
making support for cloud-init and metadata a provider requirement? Looks<br>
like all but the local provider use cloud-init (though it could)<br>
<span class="HOEnZb"><font color="#888888"><br>
Adam<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br></div></div></div>