During some exploratory testing, I ran into an issue where
the gateway would attempt to scale a deployment from zero
replicas to min, despite there already being min replicas.
Why?
The scaling logic was looking for Available replicas when
it should have looked for Desired replicas. So when a
deployment had zero ready replicas due to readiness checks
failing, the gateway was attempting to scale from zero
to min.
This logic has been corrected and separated from the
a holding pattern where the gateway waits for a ready
replica.
Tested with KinD and an edited function which had a
readiness probe, which was failing and no ready
replicas. As desired, the gateway did not scale to min.
However, when setting desired replicas to zero, the
gateway did scale up as expected.
This change also modifies all print statements for
"seconds" and makes them use 4 decimal places instead of
the default which was a longer, more verbose string for
the logs.
Signed-off-by: Alex Ellis (OpenFaaS Ltd) <alexellis2@gmail.com>
The padding was off on the Gateway UI for the function
Store popup.
I have removed the 0padding css class from this element and left
it on the elements that require it
Signed-off-by: Alistair Hey <alistair@heyal.co.uk>
This change which has been tested on armhf and x86_64 removes
the need for a separate Dockerfile for armhf.
CGO_ENABLED and GOARM etc are now passed as ARGs via build.sh.
Signed-off-by: Alex Ellis <alexellis2@gmail.com>
Code-review/refactoring for #843. Closes#843.
FaaSHandlers has had info and query handlers added to its list
of types for consistency.
Secrets added to queue-worker component ready for next PR.
Signed-off-by: Alex Ellis (VMware) <alexellis2@gmail.com>
