[RFC] baseline persist data for live-upgrade

[WeiZhang555]

As part of discussion: #492

1. kata-runtime
   A. issue "versioned" command to kata-agent, can always communicate correctly with old kata-agent. (MUST)
   B. disk persist data should be "versioned", kata-runtime can always handle old "version" of persist data to restore sandbox/container struct from disk to memory. (MUST)

The disk persist data should be "versioned" or baselined, and has a good rule for future modification. Currently we modify the data quite casually which is bad.

The persist data can include data under "/run/vc/sbs", "/var/lib/vc/sbs/" and "/run/kata-containers/", among them the "/run/vc/sbs" should be most important and difficult part.

These files including:

/run/vc/sbs/d827f23e7157863f23924f9d54d3822cd96f932f9ce53935b6fc7a1e61634b01
├── agent.json
├── d827f23e7157863f23924f9d54d3822cd96f932f9ce53935b6fc7a1e61634b01
│   ├── devices.json
│   ├── mounts.json
│   ├── process.json
│   └── state.json
├── devices.json
├── hypervisor.json
├── lock
├── network.json
├── proxy.sock
└── state.json

Based on this description, I have this proposal:

1. combine these files to one file

Currently we have many files here, and I think agent.json, devices.json, hypervisor.json, network.json and state.json can be combined to one. I don't think seperating them into several files can bring many benefits, this may bring some discussions or argues about performance penalty caused by disk writting, let's discuss whether this is real necessary.

2. baseline the persist data format.

Let me take #32 as an example, persist data format should be regarded as one kind of exported APIs.

We can create a dir virtcontainers/persist/types.go containing persist data format:

e.g.

// DeviceInfo is an embedded type that contains device data common to all types of devices.
type DeviceInfo struct {
    // Hostpath is device path on host
    HostPath string

    // ContainerPath is device path inside container
    ContainerPath string

    // Type of device: c, b, u or p
    // c , u - character(unbuffered)
    // p - FIFO
    // b - block(buffered) special file
    // More info in mknod(1).
    DevType string

    // Major, minor numbers for device.
    Major int64
    Minor int64

    // FileMode permission bits for the device.
    FileMode os.FileMode

    // id of the device owner.
    UID uint32

    // id of the device group.
    GID uint32

    // Hotplugged is used to store device state indicating if the
    // device was hotplugged.
    Hotplugged bool

    // ID for the device that is passed to the hypervisor.
    ID string

    // DriverOptions is specific options for each device driver
    // for example, for BlockDevice, we can set DriverOptions["blockDriver"]="virtio-blk"
    DriverOptions map[string]string
}

We should define all the data we want to export in a consolidated dir, and keeps an eye on any change to this dir.

And we can have a Dump() and Restore() function to convert internal structure to exported data structure and vise versa,

RunV gives a good example: https://github.com/hyperhq/runv/blob/master/hypervisor/persistence.go

[WeiZhang555]

This is quite import and I think it's prioprity 1 in my head. So ping @kata-containers/runtime for attention.

[WeiZhang555]

Basically this is another description of kata-containers/kata-containers#25 , let's keep two issue for more attention. 😛

[gnawux]

@bergwolf, @laijs, and I discussed the persistence issues before. Our thoughts is, we should have an interface like Dump/Restore or enable a pluggable persistence module (plugin). This is not only for live upgrading, but also for speed and easier integration.

[bergwolf]

@WeiZhang555

1. combine these files to one file

We should do it. It saves disk IO and makes adding other persistent storage easier.

2. baseline the persist data format.

Yes, I agree. We should revisit all persistent data fields, remove unnecessary bits and then define a v1 of it. And we should maintain the compatibility of the persistent data the same way as we maintain release compatibility.

[jshachm]

@bergwolf
Discuss in #849
Maybe we should take the first little step now~ ^_^

/cc @WeiZhang555

[WeiZhang555]

Upload a slides for AC meeting.

persist.pptx

[devimc]

@WeiZhang555 sweet, it would be nice to see them in a public gdrive

[WeiZhang555]

@devimc I'll make a copy in google docs. China has a Great Firewall which blocks google, that's why I uploaded the slides here instead of gdocs :-)

[WeiZhang555]

Slides uploaded to Google slides:
https://docs.google.com/presentation/d/1EpXEn9aq6LPqOcXg1IjjbqJUzBwTkxM8XG4O--T-ea0/edit?usp=sharing