Re: Introducing, juju resources!

[Rick Harding]

On Fri, Feb 12, 2016 at 11:06 PM Aaron Bentley 
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

Re: Introducing, juju resources!

[Nate Finch]

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 
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