/templates/packer now contains a copy of image-builder-packer repository
as of b8a4b45f93890090de24e3d043e2d958948fc3c5
Changes:
- LICENSE file was dropped (it was redundant)
- README file was dropped (no longer needed)
- GitHub workflows were removed (will be replaced by schutzbot)
- RPMs were removed (they were huge, will be installed in a different way)
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
We actually need 2 * 16 connections at minimum (one worker waits for two
jobs). Let's bump the maximum connection count even moar.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
By default, pgxpool.Pool has 4 connections (or number of cpus if higher).
Currently, we have 3 replicas, that means max 3*4=12 DB connections.
The dequeue operation is actually blocking - when a worker is waiting for
a job, one connection is blocked. My theory is that with 16 workers, we just
don't have enough connections that causes all sorts of weird slowdowns.
This commit bumps the number of connection from one replica to 10, therefore
we should be at 30 connections in total.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Use fetching the OpenAPI spec as a simple readiness/liveness, as
there is not much else we can/need to verify.
Set the default CPU and memory limits in accordance with AppSRE
requirements.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Avoid using the default account, but use a dedicated one.
This follows the guidelines from AppSRE and is what was done for
image-builder.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This should all move to app-interface, as it is configuration, and
we should distinguish between staging and production.
But for now, enable this where it is.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is backwards compatible, as long as the timeout is 0 (never
timeout), which is the default.
In case of the dbjobqueue the underlying timeout is due to
context.Canceled, context.DeadlineExceeded, or net.Error with Timeout()
true. For the fsjobqueue only the first two are considered.
