We are striving to test charms against all substrates and architectures juju supports; and are nearing completion for that goal. Manual provider is not currently tested AFAIK but will likely be in the future.
On Tue Jan 20 2015 at 7:41:27 PM Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Wed, Jan 21, 2015 at 1:36 AM, Charles Butler < > charles.but...@canonical.com> wrote: > >> Greetings, >> >> If you work on charms in any capacity: this affects you, and I would love >> to have your feedback. >> >> While working the review queue I've encountered a few charm merges that >> are failing our testing infrastructure due to missing dependencies. This >> also has implications that reach beyond our testing infrastructure: Anyone >> that is submitting a new charm, Patches being accepted to existing charms, >> and even our documentation efforts over on the Charm Authorship Docs. >> > > On this topic, does the automated testing cover testing charms with the > manual provider? There have been charms that failed (and were fixed) > because they did not explicitly install dependencies. Those charms were > using packages that are automatically installed as a result of cloud-init > being on the machine; since the manual provider does not use cloud-init, > those packages don't get automatically installed and the charms fail. IIRC, > python-yaml fits into this category. > > >> There seems to be a bit of confusion about what the recommended process >> is to ensure all our dependencies are encapsulated in the charm. >> >> Having spoken with various members of the development community, I feel >> like our dependency encapsulation process for charms is still very much a >> grey area with several different ideologies on how to manage them, thus far >> I've seen: >> >> - A Virtualenv per project to manage python dependencies >> - make targets that sudo install packages on the host system >> - Zero Dependency management >> >> This is indeed a difficult topic to approach and digest as we're >> supporting basically everything out there. Not everyone uses the same >> tool-chain to accomplish the goal of dependency isolation - and several >> different Config Management tools have a different approach to this that >> assume it is installed on the host. this leaves a broken experience for: >> >> - new charm authors >> - CI >> - Anyone that comes along and runs the test targets or bundletester >> >> If we're going to ask our community to contribute to charms, is it fair >> to make them run down dependencies that may or may not exist on their host? >> It seems like we can do a better job of highlighting this, and providing a >> quick start style development target to install these pre-deps which would >> satisfy CI and Development. With this being the proposal, I follow it with >> some questions: >> >> - How have *we* solved this problem in other areas of our ecosystem? >> - How have other platforms solved this problem? >> - Can we emulate / improve on that pattern? >> - If a package management solution exists for a technology (eg: >> virtualenv for python, bundler for ruby, npm for node, berkshelf for chef) >> - can we adopt these and get started by templating in the dependency >> management into the charm generator template? >> >> >> I'm hoping this email is seen more as a conversation starter vs me being >> pedantic - I'm more concerned with getting the right set of information to >> our users/community than I am in solving some meta problem of packaging >> charms and their Development Environments. >> >> -- >> All the best, >> >> Charles Butler <charles.but...@canonical.com> - Juju Charmer >> Come see the future of datacenter orchestration: http://jujucharms.com >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
