Juju Resources (a tool / library)
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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Juju Resources (a tool / library)
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
Re: Juju Resources (a tool / library)
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-...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Resources (a tool / library)
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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Resources (a tool / library)
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 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-...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Resources (a tool / library)
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
Re: Juju Resources (a tool / library)
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-...@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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
