Skip to content
This repository was archived by the owner on May 12, 2021. It is now read-only.

agent: support debug console#547

Merged
devimc merged 1 commit intokata-containers:masterfrom
devimc:topic/agent/cmdlineDebugConsole
May 3, 2019
Merged

agent: support debug console#547
devimc merged 1 commit intokata-containers:masterfrom
devimc:topic/agent/cmdlineDebugConsole

Conversation

@devimc
Copy link
Copy Markdown

@devimc devimc commented May 2, 2019

Start a debug console if the agent.debug_console option is part of the kernel
command line and a shell (bash or sh) is installed in the rootfs.
The debug console is useful when the developer wants to debug the agent process
or any other processes (even containers). The current way to do this is by
modifying a systemd target + creating a new system unit, the problem with this
approach is that it's not user-friendly and we depend on systemd, since it must
be installed in the rootfs.

fixes #546

Signed-off-by: Julio Montes julio.montes@intel.com

@devimc
Copy link
Copy Markdown
Author

devimc commented May 2, 2019

/test

Copy link
Copy Markdown
Contributor

@grahamwhaley grahamwhaley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
I'm happy with the way you have to both set it on the kernel line and have a shell in the VM, as that makes it feel less of a potential security hole to me.

I wonder if we can have a CI test to check this works - as this is one of the features that gets used so infrequently, but is so desirable when you need it, and it has a tendency to bitrot...

@devimc
Copy link
Copy Markdown
Author

devimc commented May 2, 2019

@jodh-intel
Copy link
Copy Markdown

kata-containers/osbuilder#96 is already open for one avenue to test ;)

Copy link
Copy Markdown

@jodh-intel jodh-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sweet! Just a query about console perms and a nit ;)

@devimc devimc force-pushed the topic/agent/cmdlineDebugConsole branch from 0b8281a to 818951f Compare May 2, 2019 18:02
@devimc devimc requested a review from a team as a code owner May 2, 2019 18:02
@devimc
Copy link
Copy Markdown
Author

devimc commented May 2, 2019

@grahamwhaley @jodh-intel changes applied, thanks

@devimc
Copy link
Copy Markdown
Author

devimc commented May 2, 2019

/test

@devimc devimc force-pushed the topic/agent/cmdlineDebugConsole branch from 818951f to 5f25782 Compare May 2, 2019 19:25
@devimc
Copy link
Copy Markdown
Author

devimc commented May 2, 2019

/test

Start a debug console if the `agent.debug_console` option is part of the kernel
command line and a shell (bash or sh) is installed in the rootfs.
The debug console is useful when the developer wants to debug the agent process
or any other processes (even containers). The current way to do this is by
modifying a systemd target + creating a new system unit, the problem with this
approach is that it's not user-friendly and we depend on systemd, since it must
be installed in the rootfs.

fixes kata-containers#546

Signed-off-by: Julio Montes <julio.montes@intel.com>
@devimc devimc force-pushed the topic/agent/cmdlineDebugConsole branch from 5f25782 to 0af7173 Compare May 3, 2019 13:06
@devimc
Copy link
Copy Markdown
Author

devimc commented May 3, 2019

/test

Copy link
Copy Markdown

@jodh-intel jodh-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @devimc!

lgtm

@grahamwhaley
Copy link
Copy Markdown
Contributor

@devimc - guess we should check why 18.04-initrd and sles CIs failed?

@devimc
Copy link
Copy Markdown
Author

devimc commented May 3, 2019

@grahamwhaley

intird

+ sudo docker run --runtime=kata-runtime -d --name kata-VDABum busybox tail -f /dev/null
5f4b7c55efe19567b657992359855cae5bb1c72197f25f73085c3472120bb7fa
docker: Error response from daemon: OCI runtime create failed: rpc error: code = Unavailable desc = transport is closing: unknown.
Makefile:126: recipe for target 'vm-factory' failed
make: *** [vm-factory] Error 125
Build step 'Execute shell' marked build as failure
Performing Post build task...
Match found for :.* : True

sles

• Failure [30.093 seconds]
[Serial Test] Update number of CPUs
/tmp/jenkins/workspace/kata-containers-agent-sles-12-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:228
  Update CPU constraint
  /tmp/jenkins/workspace/kata-containers-agent-sles-12-PR/go/src/github.com/kata-containers/tests/vendor/github.com/onsi/ginkgo/extensions/table/table.go:92
    should have 2 CPUs [It]
    /tmp/jenkins/workspace/kata-containers-agent-sles-12-PR/go/src/github.com/kata-containers/tests/vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:46

    Expected
        <int>: 1
    to be zero-valued

    /tmp/jenkins/workspace/kata-containers-agent-sles-12-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:299
------------------------------
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Summarizing 1 Failure:

[Fail] [Serial Test] Update number of CPUs Update CPU constraint [It] should have 2 CPUs 

nothing related to this pr, restarting CIs

Copy link
Copy Markdown
Contributor

@mcastelino mcastelino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Really waiting for this PR to land.

Now if we add a minimal shell by default the the kata image it would be really helpful.

@devimc devimc merged commit 39286d4 into kata-containers:master May 3, 2019
devimc pushed a commit to devimc/kata-agent that referenced this pull request Jul 30, 2019
Some containers may require HW devices to improve its performance. In Kata
containers these devices can be passed though VFIO and used in the container
only if the guest kernel has the drivers built-in for them. When kernel
fragment support landed (kata-containers/packaging#646), kata lost support
for several HW devices like Intel GPUs, this was expected since one of the
goals of this change was to have a minimal kernel in order to improve boot
time, memory footprint and reduce the attack surface by enabling just the
features required to run kata containers.
Currently if the users want to use a HW device in kata container, He/She has
to build a custom kernel and create a custom image that includes the modules
that will be loaded by systemd. From user's perspective this is a pain, since
not all users know how to create a custom image or configure/build a custom
kernel.
Same as the `debug_console` feature (kata-containers#547), the goal of
this change is to facilitate the things to the final user and *do not* depend
on systemd.

fixes kata-containers#615

see kata-containers/osbuilder#77

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-agent that referenced this pull request Jul 31, 2019
Some containers may require HW devices to improve its performance. In Kata
containers these devices can be passed though VFIO and used in the container
only if the guest kernel has the drivers built-in for them. When kernel
fragment support landed (kata-containers/packaging#646), kata lost support
for several HW devices like Intel GPUs, this was expected since one of the
goals of this change was to have a minimal kernel in order to improve boot
time, memory footprint and reduce the attack surface by enabling just the
features required to run kata containers.
Currently if the users want to use a HW device in kata container, He/She has
to build a custom kernel and create a custom image that includes the modules
that will be loaded by systemd. From user's perspective this is a pain, since
not all users know how to create a custom image or configure/build a custom
kernel.
Same as the `debug_console` feature (kata-containers#547), the goal of
this change is to facilitate the things to the final user and *do not* depend
on systemd.

fixes kata-containers#615

see kata-containers/osbuilder#77

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-agent that referenced this pull request Jul 31, 2019
Some containers may require HW devices to improve its performance. In Kata
containers these devices can be passed though VFIO and used in the container
only if the guest kernel has the drivers built-in for them. When kernel
fragment support landed (kata-containers/packaging#646), kata lost support
for several HW devices like Intel GPUs, this was expected since one of the
goals of this change was to have a minimal kernel in order to improve boot
time, memory footprint and reduce the attack surface by enabling just the
features required to run kata containers.
Currently if the users want to use a HW device in kata container, He/She has
to build a custom kernel and create a custom image that includes the modules
that will be loaded by systemd. From user's perspective this is a pain, since
not all users know how to create a custom image or configure/build a custom
kernel.
Same as the `debug_console` feature (kata-containers#547), the goal of
this change is to facilitate the things to the final user and *do not* depend
on systemd.
The list of kernel modules and their options are set through gRPC when the
sandbox is created.

fixes kata-containers#615

see kata-containers/osbuilder#77

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-agent that referenced this pull request Aug 1, 2019
Some containers may require HW devices to improve its performance. In Kata
containers these devices can be passed though VFIO and used in the container
only if the guest kernel has the drivers built-in for them. When kernel
fragment support landed (kata-containers/packaging#646), kata lost support
for several HW devices like Intel GPUs, this was expected since one of the
goals of this change was to have a minimal kernel in order to improve boot
time, memory footprint and reduce the attack surface by enabling just the
features required to run kata containers.
Currently if the users want to use a HW device in kata container, He/She has
to build a custom kernel and create a custom image that includes the modules
that will be loaded by systemd. From user's perspective this is a pain, since
not all users know how to create a custom image or configure/build a custom
kernel.
Same as the `debug_console` feature (kata-containers#547), the goal of
this change is to facilitate the things to the final user and *do not* depend
on systemd.
The list of kernel modules and their parameters are set through gRPC when the
sandbox is created.

fixes kata-containers#615

see kata-containers/osbuilder#77

Signed-off-by: Julio Montes <julio.montes@intel.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support debug console (no systemd required)

4 participants