https://github.com/juju-solutions/kubernetes/blob/master-node-split/cluster/juju/layers/kubernetes-worker/reactive/kubernetes_worker.py#L70-L74
Seems like an applicable code-first way to solve this. Matt and I have been discussing extracting these common bits of code and contributing back to charmhelpers when using resources so there are established patterns on how to address this issue. LIke set a common threshold on fillesize when invoking resource_get resource_get('mything', min_bytes='1000000') which would block on a sub 1MB resource and return. Leaving control/execution state manipulation to the charmer to handle, but still handled all the same. Any thoughts on this? or am I running down the same hallway with the same hammer looking for nails? All the best, Charles On Thu, Sep 29, 2016 at 10:06 AM Rick Harding <rick.hard...@canonical.com> wrote: > We didn't do an original 0byte resource because that's almost promised to > fail. The thought was, in order to publish the charm into the store then > you need some minimal resource that the charm will accept. If it's a django > charm, a hello world application; if a file server, a demo image; etc. Just > having a 0byte charm means the deploy is probably going to come up in some > awkward error state that the end user has to track down "why did this fail" > vs something obvious and documented. > > On Thu, Sep 29, 2016 at 10:59 AM Charles Butler < > charles.but...@canonical.com> wrote: > >> TL;DR - would it be helpful to just initialize every resource stream, at >> index 0, a zero byte resource? This aids users who are publishing charms >> with copyrighted bins, or proprietary components. And give an immediately >> publishable resource for streams. >> >> >> It occurred to me this week while we were revving through the kubernetes >> publication process, that on initial publish its best to have zero byte >> resources at index 0. So its easy to remember - "man which resource was the >> zero byte one?" it just corresponds to 0. >> >> Instead of having users touch, gzip, etc a null resource, would it be >> feasible to make the charm store have this convention by default? Every >> charm that declares a resource, that resource, in turn gets a resource-0 >> allocated for zero byte, freeing the publisher of the charm to use the >> provided null resource? seems like a better UX than asking the user to >> jump through hoops of say: >> >> touch null && gzip null && charm attach mycharm big-resource=null.gz >> >> There's likely a reason we didn't do this by default and I'm interested >> in hearing it. However, I'm more interested in finding out if we can >> streamline resource publication for our vendors and community. >> >> All the best, >> >> Charles >> -- >> 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 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