For commands that ask for JSON results, if the input to the Go JSON
marshaller is empty, it will return a byte array with a literal
"null" in it. If that is the case, we should output [] instead
as at least that is valid JSON and will not break consumers of the
data.
Signed-off-by: baude <bbaude@redhat.com>
This package is used in authenticating a user for kpod login
and can be used for authentication in kpod push, pull etc.
Signed-off-by: umohnani8 <umohnani@redhat.com>
When running the test suite interactively, "Connect to pod
hostport from the host" test hangs because nc thinks it's
got a bidirectional connection. Running with </dev/null
closes the connection after receiving the expected data,
letting the tests proceed.
This is just a suggestion for n00b-friendliness. Running
interactively is rare, but it's exactly where a n00b
will begin, and the hang costs a little time and energy
to track down.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The change in flag from debug to log-level was causing cri-o to fail when started
There was a reference to the debug flag in kpod/main.go that had not been changed
Signed-off-by: umohnani8 <umohnani@redhat.com>
Refactored rmi, images, diff, and history.
Made fixes to kpod images in the way it was handing the templates as well as printing the image names
Signed-off-by: umohnani8 <umohnani@redhat.com>
Add a man page on how to achieve the same user experience as using
kpod attach by using either the kpod logs or kpod exec commands.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We have to call hack/local-up-cluster from kubernetes directory
as it makes relative calls to cluster/kubectl.sh. The failure
of these calls led to kube-dns not coming up.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Running crio with -debug is very verbose. Having more granularity
on the log level can be useful when e.g. only looking for errors.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Under very heavy loads (e.g. 100 pods created at the same time), VM
based runtimes can take more than 10 seconds to create a pod.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When cri-o assumes the container creation failed, we need to let the
runtime know that we're bailing out so that it cancels all ongoing
operation.
In container creation timeout situations for example, failing to
explictly request the runtime for container deletion can lead to large
resource leaks as kubelet re-creates a failing container, while the
runtime finishes creating the previous one(s).
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
