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