What would you like to see in the virtual Charm School hangouts?
Mark Canonical Ramm-Christensen
mark.ramm-christensen at canonical.com
Tue May 28 20:38:13 UTC 2013
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."
If we have that stuff available in the charm, it's just up to what code
does the package installs.
If we use cloud-init we'd have to:
- special case dependency installs when we use force-machine to
do container-less co-location
- 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)
- special case it if we end up supporting other host OS's that may not
have cloud-init
So, I'm not not convinced of the value of having cloud init do this work
rather than a juju agent.
Not to mention the fact that we still haven't even decided if this is worth
putting on the priority list ;)
--Mark Ramm
On Tue, May 28, 2013 at 2:10 PM, Adam Gandelman <adamg at canonical.com> wrote:
> On 05/26/2013 08:02 AM, Mark Canonical Ramm-Christensen wrote:
> > There are multiple inter-related issues that are being discussed here:
> >
> > * making it easier to write charms in Ruby or PHP when those languages
> > are not available in the cloud image by default.
> >
> > * making it easier to support charms on private clouds that block
> > outgoing network access (egress filtering)
> >
>
> Just curious.. Why hasn't cloud-init been leveraged to address these two
> points? Seems it would be easy to expand potential charm metadata
> (additional packages, pre-install requirements, etc) or environment
> config (apt_proxy) into additional cloud-config that gets appended to
> what juju already generates. Or has it been a design decision to avoid
> making support for cloud-init and metadata a provider requirement? Looks
> like all but the local provider use cloud-init (though it could)
>
> Adam
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130528/1b7d7722/attachment.html>
More information about the Juju
mailing list