Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shimv2: support attachable binary I/O #10020

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

fahedouch
Copy link
Member

nerdctl uses binary I/O to support detached mode, but this is not sufficient because it does not allow reattachment. This PR introduces a new I/O attachablebinary that allows detaching and reattaching of I/O managed by the containerd-shim

@fahedouch fahedouch marked this pull request as draft March 29, 2024 15:50
@fahedouch fahedouch marked this pull request as ready for review April 1, 2024 09:33
@fahedouch fahedouch force-pushed the binary-io-writes-to-fifos branch 2 times, most recently from c84d44b to c3ab348 Compare April 1, 2024 09:45
@@ -107,6 +110,16 @@ func createIO(ctx context.Context, id string, ioUID, ioGID int, stdio stdio.Stdi
pio.io, err = runc.NewPipeIO(ioUID, ioGID, withConditionalIO(stdio))
case "binary":
pio.io, err = NewBinaryIO(ctx, id, u)
case "attachablebinary":
Copy link
Member

Choose a reason for hiding this comment

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

Needs godoc and test

Copy link
Member Author

Choose a reason for hiding this comment

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

test added.
I am not really sure where to add godoc cc @AkihiroSuda

Copy link
Member Author

Choose a reason for hiding this comment

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

godoc added

Copy link
Member

Choose a reason for hiding this comment

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

maybe we can merge attachablebinary with existing one, binary, by using reserve param key like _attach=true.

cc @AkihiroSuda @dmcgowan

Copy link
Member Author

Choose a reason for hiding this comment

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

I intended to merge them but I think it will introduce a non-negligible complexity and more responsibilities to NewBinaryIO() func so I prefer to make a seperate function

Copy link
Member

@mxpv mxpv Apr 27, 2024

Choose a reason for hiding this comment

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

maybe we can merge attachablebinary with existing one, binary, by using reserve param key like _attach=true.

That was my thinking too. "attachablebinary" is extended case of "binary", I like the idea of introducing attach flag. The code is indeed complex and needs some refactoring.

@fahedouch fahedouch force-pushed the binary-io-writes-to-fifos branch 2 times, most recently from a3da5f4 to b913e4c Compare April 7, 2024 21:26
@fuweid fuweid changed the title support attachable binary I/O shimv2: support attachable binary I/O Apr 19, 2024
@fahedouch fahedouch requested a review from fuweid April 21, 2024 22:05
cmd/containerd-shim-runc-v2/process/io.go Outdated Show resolved Hide resolved
@@ -107,6 +110,16 @@ func createIO(ctx context.Context, id string, ioUID, ioGID int, stdio stdio.Stdi
pio.io, err = runc.NewPipeIO(ioUID, ioGID, withConditionalIO(stdio))
case "binary":
pio.io, err = NewBinaryIO(ctx, id, u)
case "attachablebinary":
Copy link
Member

Choose a reason for hiding this comment

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

maybe we can merge attachablebinary with existing one, binary, by using reserve param key like _attach=true.

cc @AkihiroSuda @dmcgowan

return f, fmt.Errorf("failed to open stdout fifo: %w", retErr)
}
defer func() {
if retErr != nil && f.Stdout != nil {
Copy link
Member

Choose a reason for hiding this comment

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

I think we don't need to check f.Stdout != nil here.

Copy link
Member Author

Choose a reason for hiding this comment

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

yep, I also cleared some useless defer funcs

@@ -243,6 +256,16 @@ func (c *countingWriteCloser) Close() error {
return c.WriteCloser.Close()
}

type PipesReader struct {
Copy link
Member

Choose a reason for hiding this comment

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

is it required to be exported type?

Copy link
Member Author

Choose a reason for hiding this comment

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

nope, fixed

if err == nil {
return
}
result := []error{err}
Copy link
Member

Choose a reason for hiding this comment

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

please use named var defined in return parameters.

Copy link
Member Author

Choose a reason for hiding this comment

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

it is better now ?

Signed-off-by: fahed dorgaa <fahed.dorgaa@gmail.com>
@fahedouch
Copy link
Member Author

/retest

@@ -307,6 +329,180 @@ func NewBinaryIO(ctx context.Context, id string, uri *url.URL) (_ runc.IO, err e
}, nil
}

// NewAttachableBinary runs a custom binary process and opens attachable fifos for pluggable shim logging
func NewAttachableBinary(ctx context.Context, id string, uri *url.URL) (_ *cio.FIFOSet, err error) {
binaryFifos, err := cio.NewFIFOSetInDir(defaults.DefaultFIFODir, id, true)
Copy link
Member

Choose a reason for hiding this comment

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

Why terminal=true here?

err = errors.Join(result...)
}()

pipesAttachableFifosPipes, err := openAttachableFifos(ctx, attachableFifos)
Copy link
Member

Choose a reason for hiding this comment

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

Will it be problematic if there are no consumers of these FIFOs? Pipe has limited capacity and when it's full the writing side may block or fail.

Copy link
Member Author

@fahedouch fahedouch May 5, 2024

Choose a reason for hiding this comment

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

by default fifo would block when it's full, but with O_NONBLOCK flag coming data will be lost and new data will be queued to the writer(fifo), so attaching tails logs and this is the intended behavior

@cpuguy83
Copy link
Member

cpuguy83 commented May 1, 2024

Really not a fan of these runc specific options that really have nothing really to do with runc.
That said this seems fine to unblock an existing workflow.

It would also be extremely helpful to include an explanation of what this does and how its expected to be used in code and the commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants