The ItemLock API allows for taking shared and exclusive locks on all
items.
For virtcontainers, this is specialized into taking locks on the Lock
item, and will be used for sandbox locking.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The Raw API creates a raw item, i.e. an item that must be handled
directly by the caller. A raw item is one that's not defined by the
store.Item enum, i.e. it is a custom, caller defined one.
The caller gets a URL back and is responsible for handling the item
directly from this URL.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is basically a Store dispatcher, for storing items into their right
Store (either configuration or state).
There's very little logic here, except for finding out which store an
item belongs to in the virtcontainers context.
vc.go also provides virtcontainers specific utilities.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When a component creates a new store from a given root path, we add it
to the store manager and return it back when another component asks for
it.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Each virtcontainers module/component should be able to get a handler on
a Store for loading component specific items. The Store manager is an
internal Store layer for tracking all created Stores.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Store is a replacement for the current resource storage virtcontainers
implementation and the Manager is the front-end for it. The back-ends
will provide actual storage capabilities and the first one will be the
filesystem one, for storing virtcontainers Items on a local filesystem.
The main design goals for Store are the following ones:
- Simplicity: The API should be short and simple.
- Transparency: The core virtcontainers code should not care about
the storage backend details.
- Extensibility: It should be easily extensible to add non local and in
memory backends.
Manger provides a very short and simple API for the rest of the virtcontainers
code base to consume:
New: Creates a new Store, if needed.
Load: Loads an Item from a Store
Store: Stores an Item into a Store.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
If only initrd or rootfs image is installed,
allow to start Kata Containers without erroring
out.
Fixes: #1174
Signed-off-by: Nitesh Konkar niteshkonkar@in.ibm.com
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>
For example, under debian buster/sid. Those information should be
provide with best effort instead of error out. Set name and version
to "<<unknown>>" if they are not defined.
Fixes: #1177
Signed-off-by: Yang Bo <bo@hyper.sh>