Should we change `containers-mapping` into bolt db

[jshachm]

Now we mark contaienrs and sandbox with contaienrs-mapping dirs. When we what to get fetchContainerIDMapping we need to do a ioutil.ReadDir(dirPath).

Should we store the information into a db like bolt db?

Glad to hear your suggestion~
@bergwolf @egernst @sboeuf @grahamwhaley

[sboeuf]

I would say this is technically feasible but this would bring more dependency to kata-runtime. So my suggestion is that if someone's interested in doing this work, I guess we should keep the filesystem as the default configuration.

[jshachm]

@sboeuf Thx for ur response~

There are some points we found in our production env with current filesystem:

1. There are too many dirs in the host. For now we have

• /run/vc/sbs
  runStoragePath is the sandbox runtime directory. It will contain one state.json and one lock file for
  each created sandbox

• /run/vc/vm
  RunVMStoragePath is the vm directory. It will contain all guest vm sockets and shared mountpoints.
  Note that: now shared mountpoints are stored in the /var/run/kata-containers as
  defaultRootDirectory

• /var/lib/vc/sbs
  configStoragePath is the sandbox configuration directory.It will contain one config.json file for each
  created sandbox.

• /var/run/kata-containers
  serve as the default root dir, store shared mountpoint, netmon file and container mapping.

  As we tested, a lot of remaining dirs had been left. Try to make the clean easier, I think the first step is to reduce the complex of host dirs. Of cause, container-mapping is one of the points.

2. The contexts in config dir /var/lib/vc is too large and some of them are repeated in sandbox config and container config
   As it can be showed, a normal kata-container 's config file will take about 52k and the container config will take another 28k

[root@localhost 033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573]# pwd
/var/lib/vc/sbs/033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573
[root@localhost 033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573]# ll -h
total 56K
drwxr-x---. 2 root root 4.0K Oct 23 14:25 033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573
-rw-r--r--. 1 root root  52K Oct 23 14:25 config.json
[root@localhost 033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573]# cd 033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573/
[root@localhost 033a82859612f46bdec7b76397977c7ca7b2851c51f95358e3e9e24294e49573]# ll -h
total 28K
-rw-r--r--. 1 root root 27K Oct 23 14:25 config.json

Since we just compact it from the bundle path, so I think there maybe no need for store oci_spec into two configs and take such large disk space.

Wanna inputs from your guys. And maybe later we wanna to push a pr on refactoring this ~

/cc @WeiZhang555 @woshijpf

[jodh-intel]

I like the idea of a database, but I think the default should stay as-is for now as @sboeuf has said.

It appears bolt is now unmaintained and has been replaced by https://github.com/etcd-io/bbolt. But what about sqlite? Either we take the opinionated approach and choose a single database implementation, or the more flexible approach where we use a package that allows the database backend implementation to be switched easily.

Given the impact such a change would have on multiple areas (users, development, test+CI, metrics, docs, upgrading (think stable branches), etc), I suggest you raise this at one of the Architecture Committee meetings to get some clarity on this topic:

• https://katacontainers.io/ (see dates on this site)
• https://etherpad.openstack.org/p/katacontainers-2018-architecture-committee-mtgs

[jshachm]

@jodh-intel yep ,The total change is quite big. And we can start from very little~

Considering the large size of /var/lib/vc/config.go and a lot of reaped args, maybe the first step is to find out the necessary args in the config and remove the unused ones.

Like annotation, it stores oci_spec om.github.containers.virtcontainers.pkg.oci.config for merely three times :

1. in sandbox config stands for pod or sandbox
2. in sandbox config stands for container
3. in container config stands for container

Walk through the code, maybe it's good to reduce the reaps. And it's a little step to make the disk storage smaller (of cause take performance into consideration, min read and write times~~)

Considering the skip of this AC. Maybe next time , I will raise a topic on this to make it clear ~~~

[jodh-intel]

Related: kata-containers/kata-containers#25.