Re: [Review Queue] rlec, nrpe-external, nagios, squid-reverseproxy, ubuntu-repository-cache, ibm-im
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 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
Re: [Review Queue] rlec, nrpe-external, nagios, squid-reverseproxy, ubuntu-repository-cache, ibm-im
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 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 > 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
Re: [Review Queue] rlec, nrpe-external, nagios, squid-reverseproxy, ubuntu-repository-cache, ibm-im
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 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 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 > > 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. >>> - >>> >>>
