Late to this thread, but I had to add a few things to this resource

In my experience with charm development zero byte resources has been
beneficial in three areas, charm development, third party charms, and

*Charm development*. When creating a new charm that uses resources, it is
impossible to push a charm to the store without a resource. It was useful
to push a zero byte resource to get the charm up to the store before we had
the resources ready or sorted.

*Third party charms*. We already have third party charm developers using
zero byte resources so they can push their charms to the store. Those
charms require users to pay for the resources and "juju attach" them when
to the controller. Zero byte resources allow them to get their charm in the
store, and companies can still deliver software the way they want.

*Testing*. Some charms can deal with the lack of resource by falling back
to an apt-get install, or another method and then it is useful to have a
zero byte resource for testing. Some networks will not have a connection to
the charm store, so being able to test the zero byte resource is crucial
for limited network environment testing.

At least one time in early betas of Juju we got an incomplete resource,
either the file was too big or the connection was interrupted. It was not
clear to me if the "resource_get" python method threw an exception in that
case (to the best of my knowledge it simply calls resource-get command line
which may have completed). So we came up with a work around that checked
the resulting file size.

Also charms can not be tested with many of our tools until they get in the
charm store. At this time some of our tools do not support attaching local
resources so we can not test local charms with these tools. Of course we
are improving the tools but that was a legitimate blocker for charms that
use resources.

If there is disagreement on this, we don't have to make it policy we can
just use zero byte resources as a convention for the charms that
legitimately need it.

   - Matt Bruzek <>

On Thu, Sep 29, 2016 at 1:08 PM, Rick Harding <>

> Correct, the original discussion was the charm behaving differently if the
> fingerprint had changed of the resource on the remote end. However, running
> resource-get deals with only fetching the new data if the fingerprint
> changes and so there wasn't a big draw to the feature to that end.
> Now, in this way, what you're asking is for some way to tell when there is
> no resource? I guess I'm missing what the 0byte resource is giving you out
> of the gates. The charm won't work, you want to fall back? And as soon as
> the charm gets a non-0byte resource it's no longer useful.
> I really feel like that if someone wants to publish something through the
> store that they have to supply at least some bin that runs and outputs a
> clear message to the user "got get the proper bins from here" instead of
> just failing to deploy. Charm authors should be doing whatever is possible
> to fail in a clear way, through the charm, so that users are guided on the
> right path to moving forward. I don't think the charmstore or juju having
> 0byte defaults or "no resource found" is correct. It really needs to be the
> charm taking that failure and putting context and a path for the user to
> follow vs just "not found".
> On Thu, Sep 29, 2016 at 11:48 AM Charles Butler <
>> wrote:
>> We initially asked for resource fingerprints to be available before
>> fetching so we could do something less expensive.
>> That didn't make the 2.0 cut and was pushed back needing more forethought.
>> This however is a good example of why it's a better option.
>> And I had similar logic in etcd at one point. I'll be revisiting the etcd
>> later to fold offlineability back into the charm using what you've proposed.
>> If not resource : apt install
>> --
>> Juju Charmer
>> Canonical Group Ltd.
>> Ubuntu - Linux for human beings |
>> Juju - The fastest way to model your application |
>> --
>> Juju mailing list
>> Modify settings or unsubscribe at:
>> mailman/listinfo/juju
> --
> Juju mailing list
> Modify settings or unsubscribe at:
> mailman/listinfo/juju
Juju mailing list
Modify settings or unsubscribe at:

Reply via email to