pull in newer containerd v1.0.0-alpha0 via updated alpine base, update runc to
429a5387123625040bacfbb60d96b1cbd02293ab which is vendored by that version of
containerd (and also update alpine base for runc)
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
These are not needed, but we are inconsistent. Been waiting for a
quiet moment to fix this since I noticed while doing a presentation...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Lots of boilerplate for now on, will work on upstreaming that in the tool
properly if needed later.
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
```
$ fdd init &
$ fdd share /tmp/foo # serve a fresh socketpair on that path
$ fdd test /tmp/foo # read the socketpair and test that it works
```
Instead of `fdd test` (which is only useful for testing), users are expected to
connect to the unix domain socket and call `recvmsg(2)`. They will get one side
of the socketpair. Two different processes can do this and they will be able to
talk to each other.
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
- Use the new style kernel tags with the full kernel version
- Update packages with new alpine base and new/simplified Makefiles.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- IO has been upstreamed in mirage-flow-lwt
- Init.Flow.Fd has been upstreamed in mirage-flow-unix
- Init.Flow.Rawlink has been upstreamed in mirage-flow-rawlink
- Remove some dead-code in unikernel.ml
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
Currently it supports only `service start <SERVICE>`, but it could grow e.g.
`stop`, `exec` etc in the future (although you can still use `ctr` for those).
In order to be able to use go-compile.sh the containerd build needs to move
from /root/go to /go as the GOPATH.
The vendoring situation is not ideal, but since this tool wants to be an exact
match for the containerd it seems tollerable to reuse its vendoring.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This doesn't exist with newer ctr or in systems where service containers are
not started using the ctr tool. All it contains today are the stdio FIFOs,
which are not in general useful to access after container creation.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
The rootfs were containing way too much binaries and runc command where not
started in the correct directory.
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
Use the `with-cdhcpc` branch of charrua-client, which exposes `Dhcp_client_lwt`. Dhcp_client_lwt exposes similar functions to `Dhcp_client_mirage`, but does not impose the structure of a Mirage_types_lwt.ipv4_config on the returned object, rather returning the full lease; the engine can then expose whatever information from the lease it finds to be pertinent.
Signed-off-by: Mindy Preston <mindy.preston@docker.com>
