Motivation
When automating tasks often the requirement comes up to retry commands, for example when network connections are involved and commands do not return successfully immediately or if resources are temporarily not available. Sometimes a simple for-loop in bash is sufficient. Sometimes it is necessary to use additional waiting between retries, sometimes timeouts are desired. Getting all those combinations right can be tedious and error-prone so a generic "retry" command should be available in usual environments so we should provide a retry command to openSUSE distributions.
Goals
- G1: A "retry" command is submitted to openSUSE:Factory as part of a package
Execution
- Research existing approaches and distributions
- Package existing solution or develop alternative on your own
- Submit package to a devel repository and then openSUSE:Factory and work on feedback
Results
- 2022-06-11: Couldn't wait until hackweek so made it a small weekend project :D Based on what I had in https://github.com/okurz/scripts/tree/master/retry I created https://github.com/okurz/retry including proper README, license, tests, CI, spec file for a package. An according package in OBS https://build.opensuse.org/package/show/home:okurz:retry/retry setup to be triggered from github following https://linuxkamarada.com/en/2019/03/19/integrating-the-open-build-service-with-github/
- 2022-06-13: After some fixes to get the package to build preparing submission to openSUSE:Factory so created https://build.opensuse.org/package/show/home:okurz:retry_submission/retry. To my knowledge the best approach to automate submission is still something like https://github.com/os-autoinst/scripts/blob/master/os-autoinst-obs-auto-submit but in this case I did it manually, something like getting the tarball, actually obscpio, obsinfo, spec-file and replacing the services in _service and submitting all, then creating a submission to Base:System https://build.opensuse.org/request/show/982215
- 2022-06-14: The package is already in openSUSE:Factory so usable in openSUSE Tumbleweed. openSUSE Leap does not currently accept submissions to any version
- 2022-06-16: The project already received a contribution from a second person \o/ https://github.com/okurz/retry/pull/1
- 2022-06-27: Created new submission https://build.opensuse.org/request/show/985315 including the exponential backoff feature added by jbaier. Created https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/92 to use the retry feature within the openQA-in-openQA tests. Created lightning talk presentation https://v.gd/okurz_retry
Further details
There are some "best practices" like https://stackoverflow.com/questions/7449772/how-to-retry-a-command-in-bash and https://unix.stackexchange.com/questions/82598/how-do-i-write-a-retry-logic-in-script-to-keep-retrying-to-run-it-upto-5-times . There are also existing commands, like https://github.com/minfrin/retry but it seems to unmaintained and even fails to build so maybe https://github.com/okurz/scripts/blob/master/retry is a better start.
This project is part of:
Hack Week 21
Activity
Comments
-
over 3 years ago by okurz | Reply
Couldn't wait until hackweek so made it a small weekend project :D Based on what I had in https://github.com/okurz/scripts/tree/master/retry I created https://github.com/okurz/retry including proper README, license, tests, CI, spec file for a package. An according package in OBS https://build.opensuse.org/package/show/home:okurz:retry/retry setup to be triggered from github following https://linuxkamarada.com/en/2019/03/19/integrating-the-open-build-service-with-github/
-
almost 3 years ago by minfrin | Reply
While alternative implementations are great, please be careful with naming. The “retry” tool is already out the box in Debian, Ubuntu, and Nix, and in the queue for EPEL. It is currently available for Suse via copr. If you create a different tool with the same name but different command line options into opensuse it creates chaos for everyone.
-
Similar Projects
pudc - A PID 1 process that barks to the internet by mssola
Description
As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:
- The backend is written in a mixture of C and RISC-V assembly.
- The backend is actually PID1 (for real, not within a container).
- We poll and parse incoming HTTP requests ourselves.
- The frontend is a mere HTML page with htmx.
The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.
I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.
Goals
- Have a better understanding of different Linux features from user space down to the kernel internals.
- Most importantly: have fun.
Resources
OS self documentation, health check and troubleshooting by roseswe
Project Description
The aim of this hackweek project is to improve the utility "cfg2html" so that it is even more usable under SLES and perhaps also under Rancher.
cfg2html (see also https://github.com/cfg2html/cfg2html) itself is a very mature utility for collecting and documenting information of an operating system like Linux, AIX, HP-UX and others.
Goal for this Hackweek
The aim is to extend cfg2html
- for SLES and SLES-for-SAP apps, high availability
- Improve code for MicroOS 5.x, SUMA, Edge and k8s environments
- fix shellbeauity warnings
- possibly add more plugins
- SUMA/Salt integration to collect.
Resources
Required skills: Bash, shell script and the SUSE products mentioned.
https://github.com/cfg2html/cfg2html
https://www.cfg2html.com/
SUSE Health Check Tools by roseswe
SUSE HC Tools Overview
A collection of tools written in Bash or Go 1.24++ to make life easier with handling of a bunch of tar.xz balls created by supportconfig.
Background: For SUSE HC we receive a bunch of supportconfig tar balls to check them for misconfiguration, areas for improvement or future changes.
Main focus on these HC are High Availability (pacemaker), SLES itself and SAP workloads, esp. around the SUSE best practices.
Goals
- Overall improvement of the tools
- Adding new collectors
- Add support for SLES16
Resources
csv2xls* example.sh go.mod listprodids.txt sumtext* trails.go README.md csv2xls.go exceltest.go go.sum m.sh* sumtext.go vercheck.py* config.ini csvfiles/ getrpm* listprodids* rpmdate.sh* sumxls* verdriver* credtest.go example.py getrpm.go listprodids.go sccfixer.sh* sumxls.go verdriver.go
docollall.sh* extracthtml.go gethostnamectl* go.sum numastat.go cpuvul* extractcluster.go firmwarebug* gethostnamectl.go m.sh* numastattest.go cpuvul.go extracthtml* firmwarebug.go go.mod numastat* xtr_cib.sh*
GHC-9.14 and split Hadrian from GHC build by osukup
Description
Prepare openSUSE Tumbleweed project for new GHC Haskell compiler and separate builder (Hadrian) from GHC build
Goals
- have GHC-9.14 project with working compiler and if possible filled with packageset
- have Hadrian in own package built with bootstrap compiler to separate Hadrian bootstrap from ghc bootstrap
Resources
opensuse haskell package gen project