Originally raised as an issue with invalid versions to plan, but it has
been determined with air gapped environments and development versions it
is not possible to fully address that issue.
But one thing that was identified was that we can do a better job in how
we output the upgrade plan information. Kubeadm outputs the requested
version as "Latest stable version", though that may not actually be the
case. For this instance, we want to change this to "Target version" to
be a little more accurate.
Then in the component upgrade table that is emitted, the last column of
AVAILABLE isn't quite right either. Also changing this to TARGET to
reflect that this is the version we are targetting to upgrade to,
regardless of its availability.
There could be some improvements in checking available versions,
particularly in air gapped environments, to make sure we actually have
access to the requested version. But this at least clarifies some of the
output a bit.
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
we disabled the /healthz check because our test blocks one post-start
hook from finishing. Instead we should check all the other /healthz/...
endpoints before running the tests
Dan and Sascha are senior Release Managers, SIG Release leadership, and
have already been giving thoughtful reviews of the content in this
directory.
Adding them as reviewers to spread the load of SIG Release eyes on
content.
Signed-off-by: Stephen Augustus <foo@auggie.dev>
Given we're pulling the relnotes team into review, the changes to
reviewers will happen a little more frequently, which means we'll have
the same issue of needing a top-level approver to do updates that we
were trying to avoid by creating the subdirectory in the first place.
Signed-off-by: Stephen Augustus <foo@auggie.dev>
The `-q` flag is not implemented by `docker buildx`, which results in an
output:
```
WARN[0000] quiet currently not implemented.
```
In the same way, the build output is not logged to `stdout` (but
`stderr`). This means we now dump the whole build process to a file and
if the `docker buildx` command fails, then we output those logs by
printing the contents of that file. This will also reduce the overall
verbosity and aligns to the original `docker build` behavior.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
This creates a test similar to "should function for service endpoints using hostNetwork"
for dual stack tests, using the secondary clusterip / nodeip.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
