Gustavo, Can you be more specific on how it differs from the goals of resources streams? As I mentioned in my first email, I asked around to try to get specific information about the proposed feature and wasn't able to get any concrete answers or documentation. So I created this based on what I remembered from the discussions I'd heard (admittedly not much) and what I needed in the charms I was working on.
I fully intend for this library to be subsumed / obviated by core as the feature develops, and I tried to make that clear in the library README and documentation. I also intend to update the interface to match the feature as closely as possible as the proposal becomes more concrete. On Wed, Feb 11, 2015 at 2:33 PM, Gustavo Niemeyer <[email protected]> wrote: > Hi Cory, > > While it's fine and welcome to have such test bed features, it feels > like the proposal and implementation have quite different goals from > the actual resources feature we've been talking about for a while, so > as a very early suggestion and request, I would strongly recommend > renaming the feature to avoid creating ambiguity with the feature that > we intend juju to have in the long run. Having two resource > implementations and taking over important namespaces such as > resources.yaml might introduce unnecessary confusion down the road. > Instead, the project might have a nice non-generic name, and its > configuration file could also be named after it. > > > On Wed, Feb 11, 2015 at 4:17 PM, Cory Johns <[email protected]> wrote: >> Per request, the documentation is now also available on >> ReadTheDocs.org: http://jujuresources.readthedocs.org/ >> >> On Wed, Feb 11, 2015 at 11:25 AM, Cory Johns <[email protected]> >> wrote: >>> Hi all, >>> >>> (cross-posting to juju & juju-dev) >>> >>> I've created a tool / library for organizing and managing resources >>> (binary blobs, tarballs, Python packages, and, eventually, apt >>> packages) required by a charm. The idea is to be an interim tool, and >>> a test-bed for the resource features that have been discussed for the >>> future in Juju core. >>> >>> It is available on GitHub [1] and PyPI [2], and the full documentation >>> is on PythonHosted.org [3]. >>> >>> The goals of this project are: >>> >>> * Organize all external resource dependencies into a single >>> resources.yaml file >>> * Provide easy, consistent interfaces to manage, install, and mirror >>> resources >>> * CLI and Python bindings >>> * Enforce best practices, such as cryptographic hash validation >>> >>> I asked around to see if there was an existing proposal for a >>> resources.yaml file format, but couldn't find one. If someone is >>> aware of an existing spec / proposal, I'd prefer to match that as much >>> as possible. >>> >>> The current version is fully functional, and is currently being used >>> in the framework refactor of the Apache Hadoop charms (e.g., [4]). >>> >>> Note that I created this separately from Charm Helpers primarily >>> because I wanted to use it to bootstrap CH, but this also makes it >>> easier to use in Bash charms. >>> >>> My next step is to add apt-get support, but that will requiring >>> cleaning up the mirror server (possibly converting it to use squid, >>> but I may want to keep it self-contained), and learning a bit more >>> about how the apt proxy settings work. Advice here is appreciated. >>> >>> >>> [1] https://github.com/juju-solutions/jujuresources >>> [2] https://pypi.python.org/pypi/jujuresources >>> [3] http://pythonhosted.org/jujuresources/ >>> [4] >>> https://code.launchpad.net/~bigdata-dev/charms/trusty/apache-hadoop-hdfs-master/trunk >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > -- > > gustavo @ http://niemeyer.net -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
