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
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
