[Review Queue] rlec, nrpe-external, nagios, squid-reverseproxy, ubuntu-repository-cache, ibm-im

[Kevin Monroe]

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.finch at 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.wren at 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.monroe at 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 at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160624/7b1c2aba/attachment.html>