I can, but that's not the right way to proceed if you were in fact trying to implement an important feature of juju that was extensively discussed.
1. The project has a technical lead and a manager which should have the proper information to bootstrap this, or at least know who to talk to. 2. The project has a roadmap. Make sure to talk to the people in (1) to see how this fits in. 3. I'm sure there are previous documents about this, given relevance and prior conversations. You can find these documents yourself by searching through specs, or by asking people that participated in prior conversations and might have a better idea about what to search for. 4. There should be a specification about the feature, before there is an implementation. Stakeholders should review the specification and approve it before there is code. On Wed, Feb 11, 2015 at 6:40 PM, Cory Johns <cory.jo...@canonical.com> wrote: > 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 <gust...@niemeyer.net> > 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 <cory.jo...@canonical.com> 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 <cory.jo...@canonical.com> >>> 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 >>> Juju-dev@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> >> >> -- >> >> gustavo @ http://niemeyer.net -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev