One idea is to have a resource type of "directory" and upload everything in that directory. The current code has only one resource type - file. But it's copied to a directory on the unit named by the resource. So it would be pretty easy to jnstsd copy a number of files to that directory.
Of course, this would be a resources v2 feature. I'm sure there's rework that would be needed on the back end, but it certainly seems doable. We also had ideas for making a github repo as a resource, which might be an even better UX, depending on your use case. On Sat, Feb 13, 2016, 9:10 AM Rick Harding <rick.hard...@canonical.com> wrote: > On Fri, Feb 12, 2016 at 11:06 PM Aaron Bentley < > aaron.bent...@canonical.com> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 2016-02-12 04:26 PM, Katherine Cox-Buday wrote: >> > Moonstone have been working hard on a new feature coming up in Juju >> > 2.0 called "Juju Resources", and we're now at a point where we can >> > share the goodness and call for bugs/feedback! >> >> I'm glad to see you folks are working on this. On the QA side, we've >> been wanting Juju to support some kind of native blob storage, >> basically since we started. >> >> Is is necessary to enumerate the names in the charm? I'd rather we >> didn't. One of our use cases is plugins for Jenkins. The Jenkins charm >> has has a setting that tells it which plugins to install, but there's >> no predetermined list. It would be nice if the plugins could be >> retrieved in a Juju-native way, but it would be painful to have to >> update the charm every time we added a new plugin. And it would be >> bad if people ended up forking the charm just to adjust the list of >> plugins. >> >> We could bundle the plugins in a single tarfile, but then updating the >> tarfile would be annoying. For plugins, it's best if each plugin is >> its own file and there are no restrictions on the filenames. > > > Your read is correct. You must declare the resources. It's helpful to > users to know what to stick in there and for the charm to be able to handle > different items. In your case, a single tar file of the plugins you'd like > to enable could be sent up and the charm would be able to untar, loop > through them, etc. Ideally the charm would be uploaded to the store with a > standard set of plugins and folks could then customize which ones they > wanted by creating their own tar of plugins. > > I'll make sure we keep this in mind though. We've started with one file > per resource, and maybe there's an idea here of "one or more" where you > might have a charm that takes a data set file. You can deploy with a data > set, or multiple files of data that all need to be processed, rather than > building into a single file. We'll have to think it through for a future > iteration of resources. > > Rick > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
