With the 1.5 release, we made several changes:
-simplification of daemonsets
-introduction of runtimeClass
Update documentation to take this into account.
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Before the kata-deploy container image was intended to be
used with only Kubernetes. This commit adds a script for configuring
Kata to run with Docker.
This assumes > release 1.5 of Kata, as Firecracker is being configured
as well as QEMU based Kata. Note, in order for this to work, Docker must
be configured to use a block-based storage driver.
To succeed, it the following directories must be mounted:
- /opt/kata - this is the location that the kata artifacts are stored
- /run/systemd - for reloading the docker service
- /var/run/dbus - for reloading the docker service
- /etc/docker - for updating the docker configuration (daemon.json)
usage: kata-deploy-kata [install | remove]
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Simplify the yaml and combine the prior scripts. The resulting script,
kata-deploy.sh, is used for install and configuration and
removal for CRI-O and containerd. While this could be used standalone
outside of daemonsets, today it will sleep infinity after processing the
request, since it is assumed to be called by a daemon.
By checking the CRI runtime within the script itself, we no longer need
to support many daemonsets for deploy - just a single. Still requires a
seperate cleanup daemonset (for restarting the CRI runtime), and an
RBAC.
Verified with CRI-O -- containerd testing WIP
Throwing this up now for feedback since I do not bash good.
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Signed-off-by: Saikrishna Edupuganti <saikrishna.edupuganti@intel.com>
Use a new GOPATH to build image in order to avoid clashes with user's GOPATH,
otherwise user's kata agent will be used causing problem if that repository is
not up to date.
Signed-off-by: Julio Montes <julio.montes@intel.com>
New hypervisor configs could be added in the future, add
any possible new config file.
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
Now there are 2 config paths lets update both to not use
initrd by default.
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
Use a new GOPATH to build image in order to avoid clashes with user's GOPATH,
otherwise user's kata agent will be used causing problem if that repository is
not up to date.
Signed-off-by: Julio Montes <julio.montes@intel.com>
As memory hotplug for arm64 by acpi is not ready on qemu, we choose
"probe" instead. You can refer to [1] to get more infomation about
"probe". The process of memory hotplug by "probe" in kata lies below:
firstly, add memory in qemu qmp; secondly, echo the start phyical address
of that memory to /sys/devices/system/memory/probe, which will be done
through kata-agent; thirdly, excute online op, then this newly added
memory is capable to be used.
All functions in this patch will be called after "echo" op. It can be
divided into two parts:
1. create page table for that memory;
2. add that memory to memblock.
In this patch, NUMA must be turned off for not all arm64 machine supports
NUMA.
As the newly added memory should be placed from 2T to 6T which is decided
in qemu and phyical address and virtual address will be one-one mapping
when create pgd for that memory, we must config ARM64_VA_BITS as 48.
Also some configs should be turned on, especially "ARCH_MEMORY_PROBE".
We have tested this patch integrated with another patch which performed
that echo op. It works well when using "-m" in command line when start a
kata-container on aarch64 machine.
This patch derived from Maciej Bielski. You can refer to [2] to get full
infomation about it.
[1] https://www.kernel.org/doc/Documentation/memory-hotplug.txt
[2] https://lkml.org/lkml/2017/11/23/183Fixes: #309
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
In some build systems like launchpad is not possible to run neither
custom commands or hooks, hence build a snap image with `make snap` is
not feasible, to deal with this limitation, the final snapcraft.yaml
is part of the repository and all packages versions are read from versions.yaml
in the runtime repository.
fixes#305
Signed-off-by: Julio Montes <julio.montes@intel.com>
