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>
Set the exitsdir for kpod back to /var/run/crio... so kpod can benefit
from the container exit file.
Because 0 is the int32 blank value, kpod needs its own container state
struct with the omitempty removed so it can actually display 0 in
its default json output.
Signed-off-by: baude <bbaude@redhat.com>
When a user enters a CLI with a StringFlags or StringSliceFlags and does not add
a value the CLI mistakently takes the next option and uses it as a value.
This usually ends up with an error like not enough options or others. Some times
it could also succeed, with weird results. This patch looks for any values that
begin with a "-" and return an error.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Remove duplicate definitions of storage-related flags for kpod, since
we set them in helpers.bash now, and the other locations that were
also setting it were doing so after loading the definitions in
helpers.
* Set kpod storage flags after checking if we need to force use of the
"vfs" storage driver for cri-o, to make sure kpod also ends up with
the same override if we're using one.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Move kpod tests from kpod.bats to kpod_[commandname].bats
Also make sure all status checks have a echo $output before them.
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: umohnani8 <umohnani@redhat.com>
Packages are no longer available to build on RHEL and CentOS and
btrfs is not longer supported, so we should not build with it.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
When running cri-tests with cri-o, I found out that cri-o panicked
immediately with the following message. Fix it by accessing to the
labels map only if it's non-nil.
```
panic: assignment to entry in nil map
goroutine 57 [running]:
.../cri-o/server.(*Server).RunPodSandbox(0xc42048e000, 0x7efcad4cd400,
0xc42066ec90, 0xc4201703d0, 0x0, 0x0, 0x0)
.../cri-o/server/sandbox_run.go:225 +0xda5
.../cri-o/vendor/k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime
._RuntimeService_RunPodSandbox_Handler(0x21793e0, 0xc42048e000,
0x7efcad4cd400, 0xc42066ec90, 0xc4204fe780, 0x0, 0x0, 0x0, 0x0, 0x0)
.../cri-o/vendor/k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime/api.pb.go:3645 +0x279
.../cri-o/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc420
09e3c0, 0x33e79c0, 0xc4203d1950, 0xc42080a000, 0xc4202bb980, 0x33b1d58,
0xc42066ec60, 0x0, 0x0)
.../cri-o/vendor/google.golang.org/grpc/server.go:638 +0x99c
```
Signed-off-by: Dongsu Park <dongsu@kinvolk.io>
