Deploying local code

Tim Penhey tim.penhey at canonical.com
Tue Aug 16 00:48:00 UTC 2016


Hi Alexander,

Great to hear fellow kiwis interested.

The dealing with artifacts is exactly the problem that resources were 
designed to fix. A charm defines the resources it needs and as the charm 
is deployed, it also has the resources fetched.

Personally I've not used any charms yet that use or defines resources, 
but I'm sure there are some eco team folks that could point you to some 
good examples.

Cheers,
Tim

On 16/08/16 12:27, Alexander Taler wrote:
>
> Hello everyone, I'm brand new to Juju, so first I'll say thanks for the exciting
> project, I really think that Juju takes the right approach to deployment.
>
> I will be using Juju to help software development companies build deployment
> automation for their own work. The first requirements I'm focussing on are:
>  - Deploy specific revisions of their code (source or compiled)
>  - Control dependencies so that identical software can be redeployed
>
> I am thinking to approach this by creating an artefact repository within the
> model, and then having charms fetch their dependencies from this
> repository. The repository could be a caching proxy server, or be populated
> directly from the client machine.
>
> Are these already solved problems? Is anyone already working on something along
> these lines? Does my approach sound reasonable, and aligned with the future of
> Juju? I would of course be happy to contribute back anything that I develop.
>
> Also thanks to the Launchpad team, if you're listening, for the "related
> projects" feature when registering a new project; it led me to Juju.
>
> Alex
>
>



More information about the Juju mailing list