Hmph, i'll have to double check, but I'm fairly sure the resource was getting fetched every time -- even if it did not change.
Regardless, in the upgrade-hook handler, we were resource-get'ing a resource, checking its md5 against a previous md5, and if it did not match, we were removing it and calling resource-get again in a different handler. Here's what we proposed to fix that: http://bazaar.launchpad.net/~kwmonroe/charms/trusty/layer-ibm-im/switch-to-resources/revision/21#reactive/ibm-im.sh I'll report back what I find with calling resource-get multiple times when the resource doesn't change.. -Kevin On Fri, Jun 24, 2016 at 3:34 PM, Nate Finch <nate.fi...@canonical.com> wrote: > Yeah, resource-get is specifically optimized to be able to be called as > often as you want. Each one makes a network call to the controller, but > unless the resource has changed, no data will be downloaded. > > On Fri, Jun 24, 2016 at 4:24 PM Jay Wren <jay.w...@canonical.com> wrote: > >> Could you expand on the resource-get inefficiencies? >> >> The resource-get docs say this: >> >> If "resource-get" for a resource has not been run before (for the unit) >>> >>> then the resource is downloaded from the controller at the revision >>> >>> associated with the unit's application. That file is stored in the unit's >>> >>> local cache. If "resource-get" *has* been run before then each >>> >>> subsequent run syncs the resource with the controller. This ensures >>> >>> that the revision of the unit-local copy of the resource matches the >>> >>> revision of the resource associated with the unit's application. >>> >>> >>> Either way, the path provided by "resource-get" references the >>> >>> up-to-date file for the resource. Note that the resource may get >>> >>> updated on the controller for the application at any time, meaning the >>> >>> cached copy *may* be out of date at any time after you call >>> >>> "resource-get". Consequently, the command should be run at every >>> >>> point where it is critical that the resource be up to date. >>> >> >> Expanding on the inefficiencies given the above optimizations may help >> other charm writers be aware of things which may be inefficient. >> >> Thanks, >> -- >> Jay >> >> >> On Fri, Jun 24, 2016 at 1:59 PM, Kevin Monroe <kevin.mon...@canonical.com >> > wrote: >> >>> Andrew, Cory, Kostas, Pete, and I went through the queue. Here's what >>> we found: >>> >>> >>> - >>> >>> RLEC (Kostas) >>> - >>> >>> https://bugs.launchpad.net/charms/+bug/1551133 >>> - >>> >>> This charm deploys Redis Labs Enterprise Cluster that enables you >>> to install an enterprise-grade cluster for managing and running >>> multiple >>> Redis databases. >>> - >>> >>> The charm seems functional. Deploys correctly and scales. >>> - >>> >>> There are still a few points that need the attention of the >>> author: >>> - >>> >>> Opening ports >>> - >>> >>> Better testing >>> - >>> >>> Align with the new promulgation process >>> - >>> >>> nrpe-external (Cory) >>> - >>> >>> >>> >>> https://code.launchpad.net/~aluria/charms/precise/nrpe-external-master/donotremove-hostdefs/+merge/290957 >>> - >>> >>> The PR had already been approved, but to merge in accordance with >>> the new process, it needs to be moved out of the ~charmers namespace. >>> This >>> brought to light that the maintainer is no longer recommending this >>> and >>> users should transition to cs:trusty/nrpe, raising the question of >>> how to >>> handle the transition. We will apply the PR but move this to >>> ~unmaintained >>> with an announcement to transition and a possible grace period. >>> - >>> >>> squid-reverseproxy (Pete) >>> - >>> >>> >>> >>> https://code.launchpad.net/~dbuliga/charms/trusty/squid-reverseproxy/centos/+merge/287481 >>> - >>> >>> Marked as “needs fixing” due to failing tests (missing an import >>> on trusty). >>> - >>> >>> nagios (Pete) >>> - >>> >>> >>> >>> https://code.launchpad.net/~dbuliga/charms/trusty/nagios/nagios/+merge/288614 >>> - >>> >>> Code looks good -- is blocked by nrpe-external being merged, >>> however. >>> - >>> >>> Ubuntu-repository-cache (Andrew) >>> - >>> >>> >>> >>> https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/error-message-fix/+merge/292622 >>> - >>> >>> Due to the large amount of files that need to be synced this >>> fails with a timeout error. Should try to limit the amount of repos >>> synced >>> for the test. >>> - >>> >>> IBM Installation Manager (Kevin) >>> - >>> >>> https://bugs.launchpad.net/charms/+bug/1575746 >>> - >>> >>> We noticed our previous MP was inefficiently calling resource-get >>> multiple times for the fixpack (which is a real problem with large >>> resources). Fixed. >>> - >>> >>> IBM found a bug in our previous MP where we sentry’d the wrong >>> status message in the ibm-im amulet test. Fixed. >>> - Awaiting merge decision. >>> >>> >>> Let us know if you have any questions. Thanks! >>> -Kevin >>> >>> -- >>> 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
