Store bootstrap parameters in sandbox metadata

[abel-von]

1. Sandbox controller returns endpoint information including version, protocol and address when Start sandbox.
2. Endpoint information is stored Extensions of the Sandbox in db, then shim get the endpoint information from Sandbox Extensions and restore bootstrap parameters.

This is the first PR of the sandboxed Task demonstrated in draft #9574

[k8s-ci-robot]

Hi @abel-von. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[abel-von]

/cc @fuweid @dmcgowan @mxpv

[abel-von]

@fuweid @mxpv @dmcgowan Could you please take a look at this PR?

[abel-von]

/retest

[k8s-ci-robot]

@abel-von: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mxpv]

Should we add an endpoint to query shim's address directly from the running shim instance?
I'm not sure if mixing runtime data and sandbox metadata is the right approach here (strictly speaking we store metadata in database to have enough information to restore runtime representation, but we should not store runtime specific bits in the database).

[abel-von]

I think we may have to consider that every sandbox needs an endpoint for containerd to connect, no matter it is for Task API call, or other API(for example, Streaming API in #9965 ), It is because the shim sandbox controller implements by shim process so that the runtime related data like address becomes part of the sandbox metadata. For other customized sandbox controllers(may not implemented by shim), we may have no shim process, but we still serves some APIs so that containerd can manage Tasks or other stuff in sandbox, so maybe we can make this endpoint information part of sandbox's internal attributes. @mxpv

[mxpv]

@abel-von I don't object the need of this feature, there are many use cases we can benefit from this. I'm just not sure that going through metadata store as the right way to go. Why not to query shim endpoint directly from running shim instance?

[abel-von]

Why not to query shim endpoint directly from running shim instance?

I think we have to get the endpoint first and then we can call the API of the running shim. Maybe we can add the address in the response of Status API of sandbox controller?

[abel-von]

Removed the store of endpoint in sandbox db, please take a look again. @mxpv

[Burning1020]

/ok-to-test

[abel-von]

/retest

[mxpv]

Looks good!

[mxpv]

This is an impactful change, would want a few more LGTMs for awareness.
@dmcgowan @AkihiroSuda @mikebrow PTAL?

[mikebrow]

Is there a desire to add convenience functions for endpoints? some structures and code paths are using the fields of the endpoint separately some are not.

Thoughts?

[mikebrow]

nit.. seems like there is a desire to have endpoints be their own class.. but have not gone all the way with it ..