hyperstart: gRPC protocol renames #628

sameo · 2017-10-25T09:50:07Z

Rename part the execution API
Add a marshalled config file to the sandbox creation request.

TODO:

Modify callers for these API changes.
Implement gRPC <-> OCI conversion routines
Unit test the conversion routines
Unit test the structure copying API

sameo · 2017-10-25T09:50:41Z

@gnawux @bergwolf @sboeuf @mcastelino PTAL

bergwolf · 2017-10-25T10:19:42Z

Is the new field in sandbox creation request required by clear container or is it added just for compatibility with current hyperstart protocol?

cc @laijs @gao-feng

sameo · 2017-10-25T11:19:46Z

@bergwolf The config field in the sandbox is needed for the new clear containers agent, that is based on libcontainer. It needs to get an OCI config file to set the container inside the VM.

bergwolf · 2017-10-25T12:27:44Z

@sameo The StartSandbox() operation is supposed to set pod level configurations (hostname and dns) inside the guest, while AddContainer() is the one adding new containers to the sandbox. If libcontainer needs the OCI spec details, how about passing it through AddContainer() instead? The idea is to separate container creation from sandbox creation.

It seems libcontainer also has its own config and converts OCI spec to it in specconv.CreateLibcontainerConfig(). Is it the one requiring OCI spec in the new agent?

sameo · 2017-10-25T14:06:08Z

@bergwolf

how about passing it through AddContainer() instead?

Yes, that makes sense. I updated the PR.

It seems libcontainer also has its own config and converts OCI spec to it in specconv.CreateLibcontainerConfig(). Is it the one requiring OCI spec in the new agent?

Yes.

bergwolf · 2017-10-26T02:09:22Z

hyperstart/api/grpc/hyperstart.proto

-	rpc WaitProcess(WaitProcessRequest) returns (WaitProcessResponse); // wait & reap like waitpid(2)
+	rpc CreateContainer(CreateContainerRequest) returns (google.protobuf.Empty);
+	rpc StartContainer(StartContainerRequest) returns (google.protobuf.Empty);
+	rpc Exec(ExecRequest) returns (google.protobuf.Empty);


We should be able to combine StartContainer and Exec just like above AddProcess does. Is there any special requirement to separate starting container and exec?

Yes we can merge both StartContainer() and Exec() into StartProcess() since that's what this is. We have CreateContainer() which really means that we are creating a container but without starting any process in it. And we could have StartProcess() having a flag to make the difference between the container process or any other process that we want to start.

But at the same time, I think it might be okay to have separate functions for each case since there are 2 distincts use cases. The question is, do we mind having some kind of overlapping behaviors ? I think it's okay, the agent implementation will rely on the same code for the main part of those 2 functions.

@bergwolf From a code perspective, they will look very similar, but from an API perspective they have different semantics (Their arguments are even different, you don't need to specify a Process when starting an already created container). So I think the API is clearer and more explicit with those 2 separated.

I tend to think we should keep the API list short. But I can live with this. @laijs @gnawux @gao-feng what do you guys think?

laijs · 2017-10-26T10:17:15Z

hyperstart/api/grpc/hyperstart.proto

+	// config is a marshalled OCI configuration JSON file (a.k.a. config.json).
+	// This is optional and can be used by agents implementing the hyperstart protocol to apply
+	// any resource or security constraints defined by this configuration.
+	string config = 3;


I prefer defining the desired fields in the message type Container&Process.
I don't want an embedded string with another language(json).
We might not use the OCI configuration JSON in the hyperstart since we will use libcontainer directly.

How about simply putting the OCI specs.Spec and specs.Process in place (with named fields instead of dummy string)? libcontainer in the new agent can use them directly and we do not have to modify hyperstart protocol every time when we want to add new supported fields. Of course it would add a dependency on OCI spec versions but I think it is OK since we want to be OCI compliant anyway.

@laijs @bergwolf Defining or copying the right field would be ideal, but that means copying most of the OCI specs.Specs in this file as there is no OCI specification gRPC proto file.
If that is what you want, I'll create an oci.proto separate file to not pollute the hyperstart.proto one.

oci.proto sounds good. But it should be along with a verification code(or tool) to prove that the oci.proto and the imported OCI specs are fully matched.

@laijs @bergwolf I'm implementing oci.proto and because of gRPC Go conversion assumptions, we will have to handle 2 different structures:

The gRPC generated Go structure:

type Spec struct { Version string `protobuf:"bytes,1,opt,name=Version" json:"Version,omitempty"` Process *OCIProcess `protobuf:"bytes,2,opt,name=Process" json:"Process,omitempty"` Root *Root `protobuf:"bytes,3,opt,name=Root" json:"Root,omitempty"` Hostname string `protobuf:"bytes,4,opt,name=Hostname" json:"Hostname,omitempty"` Mounts []*Mount `protobuf:"bytes,5,rep,name=Mounts" json:"Mounts,omitempty"` Hooks *Hooks `protobuf:"bytes,6,opt,name=Hooks" json:"Hooks,omitempty"` Annotations map[string]string `protobuf:"bytes,7,rep,name=Annotations" json:"Annotations,omitempty" protobuf_key:"bytes,1,opt,name=key" protobuf_val:"bytes,2,opt,name=value"` Linux *Linux `protobuf:"bytes,8,opt,name=Linux" json:"Linux,omitempty"` }

The OCI Spec Go structure:

type Spec struct { Version string `json:"ociVersion"` Process *Process `json:"process,omitempty"` Root Root `json:"root"` Hostname string `json:"hostname,omitempty"` Mounts []Mount `json:"mounts,omitempty"` Hooks *Hooks `json:"hooks,omitempty" platform:"linux,solaris"` Annotations map[string]string `json:"annotations,omitempty"` Linux *Linux `json:"linux,omitempty" platform:"linux"` Solaris *Solaris `json:"solaris,omitempty" platform:"solaris"` Windows *Windows `json:"windows,omitempty" platform:"windows"` }

As you can see those are different structures and we will have to go through the following steps:

runtime (host) -> OCI spec structure ---- conversion ----> gRPC spec structure -> gRPC binary -> gRPC structure --- conversion ----> OCI spec structure -> agent (guest)

So by not tunnelling a marshalled OCI spec through gRPC, we're adding 2 additional conversion layers: from OCI to gRPC (on the host) and then from gRPC to OCI (on the guest).

Are we all ok with that ?

cc @jodh-intel

cc @laijs @bergwolf Are we all good with the above approach?

@sameo can you please share your oci.proto? I did some preliminary test and grpc-go did generate expected spec struct w.r.t. the Solaris *Solaris field. So I want to understand the issue first.

PS, my test is here

@bergwolf Here is mine: https://gist.github.com/sameo/d8dc8c8720a67ae92100fc6d75f78987

For all non scalar fields, gRPC will generate a pointer to the struct. So if you create the Mount message in your test, you will see that Spec becomes:

type Spec struct { Version string `protobuf:"bytes,1,opt,name=Version" json:"Version,omitempty"` Process *OCIProcess `protobuf:"bytes,2,opt,name=Process" json:"Process,omitempty"` Root *Root `protobuf:"bytes,3,opt,name=Root" json:"Root,omitempty"` Hostname string `protobuf:"bytes,4,opt,name=Hostname" json:"Hostname,omitempty"` Mounts []*Mount `protobuf:"bytes,5,rep,name=Mounts" json:"Mounts,omitempty"` Hooks *Hooks `protobuf:"bytes,6,opt,name=Hooks" json:"Hooks,omitempty"` Annotations map[string]string `protobuf:"bytes,7,rep,name=Annotations" json:"Annotations,omitempty" protobuf_key:"bytes,1,opt,name=key" protobuf_val:"bytes,2,opt,name=value"` Linux *Linux `protobuf:"bytes,8,opt,name=Linux" json:"Linux,omitempty"` }

and for example you get Mounts []*Mount as opposed to Mounts []Mount for the OCI spec.

@laijs @bergwolf What about something more structured than my initial proposal:

diff --git a/hyperstart/api/grpc/hyperstart.proto b/hyperstart/api/grpc/hyperstart.proto index 7a062ad..2041cec 100644 --- a/hyperstart/api/grpc/hyperstart.proto +++ b/hyperstart/api/grpc/hyperstart.proto @@ -35,10 +35,25 @@ service HyperstartService { message CreateContainerRequest { Container container = 1; Process init = 2; - // config is a marshalled OCI configuration JSON file (a.k.a. config.json). - // This is optional and can be used by agents implementing the hyperstart protocol to apply - // any resource or security constraints defined by this configuration. - string config = 3; + + // spec is the container specification. + // With OCI its payload will be a marshalled config.json. + Spec spec = 3; +} + +message Spec { + enum SpecType { + OCI = 0; + } + + // type is the specification type. For now we only support OCI. + SpecType type = 1; + + // version is the specification version + string version = 2; + + // payload is the marshalled specification payload, e.g. config.json. + string payload = 3; } message StartContainerRequest {

laijs · 2017-10-26T10:19:42Z

hyperstart/api/grpc/hyperstart.proto

-	string container = 1;
+message StartContainerRequest {
+	string container_id = 1;
+}


I agree on separating AddContainer() into CreateContainer and StartContainer().

laijs · 2017-10-26T10:25:11Z

hyperstart/api/grpc/hyperstart.proto

+	rpc StartContainer(StartContainerRequest) returns (google.protobuf.Empty);
+	rpc Exec(ExecRequest) returns (google.protobuf.Empty);
+	rpc Signal(SignalRequest) returns (google.protobuf.Empty);
+	rpc Wait(WaitRequest) returns (WaitResponse); // wait & reap like waitpid(2)


The names with "Process" would be clearer.
How about ExecProces()(renamed from AddProcess()) SignalProcess() WaitProcess()(unchanged)?

@laijs Fine with me. Done.

sameo · 2017-11-02T14:41:19Z

@laijs @gnawux @bergwolf Initial oci.proto added.

sboeuf · 2017-11-03T14:26:22Z

hyperstart/api/grpc/hyperstart.proto

-message AddProcessRequest {
-	string container = 1;
+message ExecProcessRequest {
+	string container_id = 1;


Just a thought about the syntax. Why don't we use containerID here instead of container_id ?

Because protoc translate foo_id into fooID when being told to compile a .proto file to Go.
See hyperstart.pb.go in this PR.

sboeuf · 2017-11-03T14:55:29Z

hyperstart/api/grpc/hyperstart.proto

 	Container container = 1;
 	Process init = 2;
+	Spec OCI = 3;


I agree we need this in order to give all the information related to the container.
However, I am not very familiar with the gRPC code/protocol and I was wondering why we need to specify this Spec in details ? I mean we could use an array of bytes (basically a string) as the third parameter here. From the runtime, we marshal whatever Spec structure we want and from the agent, we unmarshal based on the same structure. I am mentioning this because having the entire spec described here means that we would have to change the protocol if we wanted a new field in the spec.

It might be worth pointing out here that this representation implies that the agent process must be updated "in lock step" with (at the same time as) the other system gRPC elements. For example, if oci.proto is updated to support a new version of the OCI spec (and Spec.Version is increased) that will clearly alter the format of the messages meaning the agent won't be able to unpack them unless it too has been updated to handle OCI.Version. It won't know that though as, ironically, it won't be able to unpack the OCI message to query Version and check if it can handle that.

It also potentially implies that the agent might need to support older versions of the spec which don't actually change the representation of Spec (but might for example have certain fields that are mandatory whereas a newer version of the spec makes them optional).

The above has an impact on system upgrade: it implies that if the gRPC format changes, all containers need to be stopped (or restarted) to pick up the new gRPC message formats (and associated assets including the new agent).

sameo · 2017-11-03T17:53:13Z

@gnawux @laijs Now with the reflection based conversion routines. I have an initial unit tests proving those routines work as expected. PTAL

sameo · 2017-11-03T17:55:15Z

cc @markdryan

laijs · 2017-11-06T09:11:18Z

hyperstart/api/grpc/utils.go

+	}
+
+	for i := 0; i < to.NumField(); i++ {
+		if err := copyValue(to.Field(i), from.Field(i)); err != nil {


I think it should be copied based on the filed name instead of the index.

@laijs I thought about that option but I'd rather avoid it due to this documented bug:
https://golang.org/pkg/reflect/#pkg-note-BUG

Since they can be decoded from json string, which conversion is based on the filed names/tags. I think the problem can be resolved here. (https://github.com/golang/go/blob/a3e013b0824ba53168b5d91abdb6ce191510a89d/src/encoding/json/encode.go#L1231)

I'm worried when the oci spec is changed in future, how would we maintain the compatibilities. (vs. older gRPC, vs. older OCI, and vs. newer OCI)? I seams that copying manually field by field is good. We can use this code, because we can change it to "manually copying" any time when any problem happen, or to a new method any time when we found one.

@laijs I'm not sure if you're asking for a change here or not. Implementing something similar to the JSON implementation means we would have to maintain additional metadata for all our fields, sort them through a similar function as well, etc...I believe this is an overkill.
I can add an additional check to verify that we're copying fields with the same name and error out when/if we're not. Any OCI config incompatibility would then be caught at unit testing time.

@laijs I changed the logic in copyStructValue to verify that:

We copy from fields with the same name

If fields don't have the same name, then we go through a loop searching for the right field in the from structure.

@laijs I think having this full OCI specification structure will be a pain to maintain. Don't you think that having only a string field would be easier ? I mean we could pass the entire config.json file serialized as a JSON and we would unmarshal from the agent. That way, we just need to make sure that both runtime and agent rely on the same OCI spec version. I don't see any benefits in having this described into the gRPC protocol description here.

laijs · 2017-11-06T09:12:27Z

hyperstart/api/grpc/utils.go

+	"reflect"
+
+	"github.com/opencontainers/runtime-spec/specs-go"
+)


It is very nice to provide this utils. It is very useful.

markdryan · 2017-11-06T10:46:09Z

hyperstart/api/grpc/utils.go

+	toVal = toVal.Elem()
+	fromVal = fromVal.Elem()
+
+	if toVal.NumField() != fromVal.NumField() {


This check isn't really needed as it is performed again in copyStructValue.

markdryan · 2017-11-06T10:48:46Z

hyperstart/api/grpc/utils.go

+			if from.Type() != to.Type() && from.Type().ConvertibleTo(to.Type()) {
+				to.Set(from.Convert(to.Type()))
+				return nil
+			} else {


The case where the types are different and not convertible is not really handled. We'll fall into this if statement and presumably panic. Is this an error case we want to handle explicitly or is the intention to trap the panic at a higher level?

markdryan · 2017-11-06T10:51:06Z

hyperstart/api/grpc/utils.go

+
+	for j := 0; j < mapLen; j++ {
+		if err := copyValue(to.Index(j), from.Index(j)); err != nil {
+			return err


I think this code will panic. Value.Index(int) cannot be used on maps. There are MapIndex and SetMapIndex functions that can be used instead.

markdryan · 2017-11-06T10:55:41Z

hyperstart/api/grpc/utils.go

+		switch toKind {
+		case reflect.Struct:
+			return copyStructValue(to, from)
+		case reflect.Slice:


Do you need to handle arrays as well? They have a different reflection type.

@markdryan We do not need to support arrays for now.

markdryan · 2017-11-06T10:56:57Z

hyperstart/api/grpc/utils.go

+}
+
+func copyStruct(to interface{}, from interface{}) error {
+	toVal := reflect.ValueOf(to)


You may want to consider trapping panics and returning an error here just in case there's an error case that isn't explicitly handled by the code.

sameo · 2017-11-06T14:48:45Z

Unit tests added and I also addressed @markdryan comments.

laijs · 2017-11-10T07:56:27Z

hyperstart/libhyperstart/hyperstart.go

 	RestoreContainer(c *hyperstartapi.Container) error
-	AddProcess(container string, p *hyperstartapi.Process) error
+	ExecProcess(container string, p *hyperstartapi.Process) error


the hyperstartapi here is actually hyperstart json + serial API.
We are going to covert this interface to use hyperstart grpc API directly.
But it needs more changes and needs to be suspended until the grpc API become a little more mature.
This is just for your information.

laijs · 2017-11-10T08:33:50Z

hyperstart/api/grpc/oci.proto

+	int64 Major = 1;
+
+	// Minor is the device's minor number.
+	int64 Minor = 2;


The test doesn't test the copying about it, which is required and important since LinuxWeightDevice in oci.Specs embeds linuxBlockIODevice as an anonymous field here.

Good point. I fixed it now and the code supports copying embedded structures.

jodh-intel · 2017-11-13T09:37:40Z

hyperstart/api/grpc/oci.proto

+	string Mems = 7;
+}
+
+message linuxBlockIODevice {


This can be dropped I think as the members are now part of LinuxWeightDevice and LinuxThrottleDevice.

ah, good call. I will update oci.proto

@jodh-intel Done

jodh-intel · 2017-11-13T09:41:03Z

hyperstart/api/grpc/oci.proto

+	OCIProcess Process = 2;
+
+	// Root configures the container's root filesystem.
+	Root Root = 3;


Shouldn't this (and all the other optional entries like ConsoleSize, Mounts, ...) be annotated with optional to comply as closely as possible with the OCI spec?

@jodh-intel The latest protobuf version (v3) no longer supports optional:
https://developers.google.com/protocol-buffers/docs/reference/go-generated#fields

That's unfortunate, but seems it's been a long debated design decision among the protobuf community members.

Ah - thanks. I wasn't aware of that.

jodh-intel · 2017-11-13T09:58:47Z

hyperstart/api/grpc/hyperstart.proto

 	Container container = 1;
 	Process init = 2;
+	Spec OCI = 3;


It might be worth pointing out here that this representation implies that the agent process must be updated "in lock step" with (at the same time as) the other system gRPC elements. For example, if oci.proto is updated to support a new version of the OCI spec (and Spec.Version is increased) that will clearly alter the format of the messages meaning the agent won't be able to unpack them unless it too has been updated to handle OCI.Version. It won't know that though as, ironically, it won't be able to unpack the OCI message to query Version and check if it can handle that.

It also potentially implies that the agent might need to support older versions of the spec which don't actually change the representation of Spec (but might for example have certain fields that are mandatory whereas a newer version of the spec makes them optional).

The above has an impact on system upgrade: it implies that if the gRPC format changes, all containers need to be stopped (or restarted) to pick up the new gRPC message formats (and associated assets including the new agent).

sameo · 2017-11-13T10:50:50Z

@jodh-intel

It might be worth pointing out here that this representation implies that the agent process must be updated "in lock step" with (at the same time as) the other system gRPC elements. For example, if oci.proto is updated to support a new version of the OCI spec (and Spec.Version is increased) that will clearly alter the format of the messages meaning the agent won't be able to unpack them unless it too has been updated to handle OCI.Version. It won't know that though as, ironically, it won't be able to unpack the OCI message to query Version and check if it can handle that.

Yes, that's correct. A few comments:

We could somehow mitigate that by adding a redundant Version field to an OCISpec message that would contain the version and the Spec itself. At least the agent would know which version of the spec it receives and could act upon it or return a meaningful warning (I don't think it should error out when failing to unpack the gRPC OCI spec message).
The OCI specs are backward compatible and follow the semver 2.0.0 semantics. So we are guaranteed (famous last words) that we would have to do the lockstep changes only when moving to a new major OCI spec version. In which case I think the overall project should also move to a new major version as well. I don't think it's reasonable to claim that e.g. Clear Containers 3.x will support both OCI 1.x and 2.x.

- Rename part the execution API - Add an OCI specification field to ContainerCreateRequest Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

We use the reflection package to avoid implementing error prone manually converting routines. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

We try to check that all supported types are properly converted. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

The gRPC generated Go structures will never have embedded fields, while the OCI ones have some. This forces us to support copying between structs with different number of fields when one field is embedded on one side while it's not on the other. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

jodh-intel · 2017-11-13T11:31:47Z

I've just found the Any message type which looks like it might offer an alternative way to represent the OCI spec:

https://developers.google.com/protocol-buffers/docs/proto3#any

sameo · 2017-11-13T17:13:27Z

@laijs Do you have any other concerns/comments on this PR?

gnawux · 2017-11-14T01:44:15Z

I think it in a good shape now, we could push it forward.

sboeuf · 2017-11-20T17:54:36Z

Why is this still not merged ?

laijs · 2017-11-21T01:22:40Z

could you remove the last grpc stream commit, and I merge it? @sameo
let grpc stream go with a new pr.

laijs · 2017-11-21T01:27:25Z

@sboeuf I felt the API not completed. Example, it seems the storage APIs still missing.
The other part can go within new PRs. I will merge this one.

sameo · 2017-11-21T09:09:27Z

@laijs Streams commit removed.

gnawux · 2017-11-21T09:15:59Z

@laijs @sameo @bergwolf @sboeuf @jodh-intel Based on our discussion on skype, I will send pr of the protocol to kata-containers/runtimes repo, which will help us accelerating the following discussion and development. I will take a snapshot of the protocol in this PR, and we could move our discussion to the correspond new PR.

sameo · 2017-11-21T09:32:04Z

@gnawux thx

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 Signed-off-by: Wang Xu <gnawux@gmail.com>

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 and kata-containers/runtime#2

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 and kata-containers/runtime#2 Signed-off-by: Wang Xu <gnawux@gmail.com>

sameo force-pushed the topic/hyperstart-grpc branch from 4a089f2 to 3033895 Compare October 25, 2017 14:05

sameo force-pushed the topic/hyperstart-grpc branch from 3033895 to 2d94857 Compare October 25, 2017 16:07

bergwolf reviewed Oct 26, 2017

View reviewed changes

laijs reviewed Oct 26, 2017

View reviewed changes

sameo force-pushed the topic/hyperstart-grpc branch 2 times, most recently from 747f410 to fea976b Compare November 2, 2017 14:40

sameo force-pushed the topic/hyperstart-grpc branch from fea976b to 5c9137b Compare November 2, 2017 14:44

sboeuf reviewed Nov 3, 2017

View reviewed changes

sameo force-pushed the topic/hyperstart-grpc branch from 5c9137b to 20c4326 Compare November 3, 2017 17:50

sameo force-pushed the topic/hyperstart-grpc branch from 20c4326 to 55b5aa4 Compare November 3, 2017 17:56

laijs reviewed Nov 6, 2017

View reviewed changes

markdryan reviewed Nov 6, 2017

View reviewed changes

sameo force-pushed the topic/hyperstart-grpc branch from 55b5aa4 to 3ff767b Compare November 6, 2017 14:47

sameo force-pushed the topic/hyperstart-grpc branch 4 times, most recently from 81813bb to c5197c1 Compare November 7, 2017 13:28

laijs reviewed Nov 10, 2017

View reviewed changes

sameo force-pushed the topic/hyperstart-grpc branch from f8bdb53 to 359f5d3 Compare November 10, 2017 13:19

jodh-intel reviewed Nov 13, 2017

View reviewed changes

Samuel Ortiz added 5 commits November 13, 2017 12:02

hyperstart: gRPC protocol renames

2d9bbd1

- Rename part the execution API - Add an OCI specification field to ContainerCreateRequest Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

hyperstart: Add OCI <-> gRPC conversion routines

7554b39

We use the reflection package to avoid implementing error prone manually converting routines. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

utils: Add a OCI to gRPC conversion unit test

a8bf456

We try to check that all supported types are properly converted. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

utils: Add copyValue() unit tests

7f65bf9

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

sameo force-pushed the topic/hyperstart-grpc branch from 359f5d3 to e33dd53 Compare November 13, 2017 11:03

sameo force-pushed the topic/hyperstart-grpc branch from 5f41cf0 to e33dd53 Compare November 21, 2017 08:58

gnawux added a commit to gnawux/kata-runtime that referenced this pull request Nov 21, 2017

Initial gRPC protocol for agent communication

9637f24

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 Signed-off-by: Wang Xu <gnawux@gmail.com>

gnawux mentioned this pull request Nov 21, 2017

[RFC ]Initial gRPC protocol for agent communication kata-containers/runtime#2

Closed

gnawux added a commit to gnawux/kata-runtime that referenced this pull request Nov 21, 2017

Initial gRPC protocol for agent communication

7cb7865

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 Signed-off-by: Wang Xu <gnawux@gmail.com>

gnawux added a commit to gnawux/kata-agent that referenced this pull request Nov 23, 2017

Initial gRPC protocol for agent communication

5233ccc

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 and kata-containers/runtime#2

gnawux added a commit to gnawux/kata-agent that referenced this pull request Nov 23, 2017

Initial gRPC protocol for agent communication

b79c7d4

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 and kata-containers/runtime#2 Signed-off-by: Wang Xu <gnawux@gmail.com>

gnawux mentioned this pull request Nov 23, 2017

[RFC] Initial gRPC protocol for agent communication kata-containers/agent#2

Merged

gnawux added a commit to gnawux/kata-agent that referenced this pull request Nov 23, 2017

Initial gRPC protocol for agent communication

4de0d74

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 and kata-containers/runtime#2 Signed-off-by: Wang Xu <gnawux@gmail.com>

gnawux added a commit to gnawux/kata-agent that referenced this pull request Nov 23, 2017

Initial gRPC protocol for agent communication

22a3236

based on hyperstart gRPC protocol and the discussion in hyperhq/runv#628 and kata-containers/runtime#2 Signed-off-by: Wang Xu <gnawux@gmail.com>

laijs closed this Nov 29, 2017

hyperstart: gRPC protocol renames #628

hyperstart: gRPC protocol renames #628

Conversation

sameo commented Oct 25, 2017 • edited Loading

sameo commented Oct 25, 2017

bergwolf commented Oct 25, 2017

sameo commented Oct 25, 2017

bergwolf commented Oct 25, 2017 • edited Loading

sameo commented Oct 25, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sameo Nov 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sameo commented Nov 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sameo commented Nov 3, 2017

sameo commented Nov 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markdryan Nov 6, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sameo commented Nov 6, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sameo commented Nov 13, 2017

jodh-intel commented Nov 13, 2017

sameo commented Nov 13, 2017

gnawux commented Nov 14, 2017

sboeuf commented Nov 20, 2017

laijs commented Nov 21, 2017

laijs commented Nov 21, 2017

sameo commented Nov 21, 2017

gnawux commented Nov 21, 2017

sameo commented Nov 21, 2017

sameo commented Oct 25, 2017 •

edited

Loading

bergwolf commented Oct 25, 2017 •

edited

Loading

sameo Nov 1, 2017 •

edited

Loading

markdryan Nov 6, 2017 •

edited

Loading

sameo commented Nov 6, 2017 •

edited

Loading