@scafide thanks A TON for making retry a reality. This is HUGE, even if it took 8 years to happen, thanks for going to bat for us. :)
QUESTION: does the new retry feature introduced in 10.23.0 have a maximum number of retry attempts limit?
When we moved from SMB to HTTP/HTTPS some years ago, we did it for the resumable downloads feature. After we started using the feature, and running into failed download issues, we found out there is a 5 minute time limit for resumable downloads, after which the policy will fail. It was explained to us that this was intentional, so the jamf client can move on to the next policy.
Compared to how the existing resumable downloads feature works, would the new retry feature try forever, or would it stop trying after N retry attempts?
Scenario. We are tasked with deploying macOS Combo Updates, as well as macOS full installers. These babies weigh in at several GBs. So we cache the package to all computers that meet requirements, and a Self Service policy is scoped to computers that have the package cached.
Before the retry feature, we had to check the cache policy. Every. Single. Day. To see if there were any failures, and flushing any failures so the cache policy can run again.
The new retry feature eliminates what has been a very annoying and time consuming task. That said, is there a maximin number of retries before retry gives up and moves on to the next policy (ala resumable downloads)?
COVID being a thing, many or all users may be home, connected by VPN. Where VPN (or the user's internet provider) might have a data or time limit, causing a cache policy to fail. In this scenario having retry never stop trying is not a good thing. So knowing if there is a maximum number of retry attempts is useful knowledge, when we are designing policy workflows, creating Help Desk documentation, etc.
Thanks again for making retry a reality...ether beer for you at the next virtual conference. :)
Hey Don,
Thanks for the shoutout here and sorry for the long wait, we definitely didn't forget about it! We're excited to be able to deliver this in an attempt to make policy a bit more persistent and resilient. So the retry event (at this time) can be tied to either the check-in, or the next selected trigger occurrence with a maximum of 10 retries. We wanted to avoid having the retry attempts occur within the same trigger event at an arbitrary or configurable time value. I hope this provides some clarity to the feature. If I missed the mark here or didn't quite answer your question, feel free to reach out.
Cheers!
Now if my design sensibilities can get beyond the "Retrying Disabled" text hanging out of the bounding box, we'd be in real
business.
