Late to this thread, but I had to add a few things to this resource discussion.
In my experience with charm development zero byte resources has been beneficial in three areas, charm development, third party charms, and testing. *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 <matthew.bru...@canonical.com> On Thu, Sep 29, 2016 at 1:08 PM, Rick Harding <rick.hard...@canonical.com> wrote: > 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 < > charles.but...@canonical.com> 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 | www.ubuntu.com >> Juju - The fastest way to model your application | www.jujucharms.com >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
