It always fails because conmon is still there.
But more importantly it adds a 2 seconds delay to the container
creation as we're trying to delete a cgroup but we can't.
With this patch a container creation is down to typically less than
150ms instead of 2+ seconds.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The bats "run" helper function sets "$status", so there's no point to
checking the value of "$status" when we haven't used the "run" helper to
run a command, and we almost always want to be checking the value after
we have used the helper.
There's no need to run commands like 'sleep' or 'rm -f' with the helper,
since they're not expected to fail, and if they do, it's probably
indicative of a larger problem that we want to allow to cause tests to
fail.
Helper functions like start_crio already check "$status" when they call
"run", so we don't need to check it again after they return.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
In the kpod-stop-by-name test, use 'kpod inspect' to look up the name of
the container, rather than predicting the name that crio will assign.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Allows the user to define secret paths in /etc/containers/mounts.conf
These are then volume mounted into the container
Signed-off-by: umohnani8 <umohnani@redhat.com>
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>
