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

Remove exec from required runtime functionalities. #388

Merged
merged 1 commit into from
Apr 20, 2016

Conversation

vishh
Copy link
Contributor

@vishh vishh commented Apr 19, 2016

Exec can be implemented as running additional containers.

For #345

@vishh
Copy link
Contributor Author

vishh commented Apr 19, 2016

cc @mrunalp @crosbymichael

@wking
Copy link
Contributor

wking commented Apr 19, 2016

On Tue, Apr 19, 2016 at 10:53:58AM -0700, Vish Kannan wrote:
“* Remove exec from required runtime functionalities. Exec can be”

Probably want two newlines instead of the period to avoid the
long-subject error 1.

@wking
Copy link
Contributor

wking commented Apr 19, 2016

Do we want to put suggestions about implementing exec in an
informative section somewhere? I'd guess the template is:

{
"ociVersion": … usual stuff…,
"platform": … usual stuff…,
"process": … what you want to exec…,
"root": what to put here?
"linux": {
"cgroupsPath": … extracted from state JSON…,
"namespaces": [
{
"type": "pid",
"path": … extracted from state JSON…
},

]
}
}

The namespace paths and cgroupsPath would come from a procfs entry,
which you'd find by:

  1. Get state JSON using the ‘state ’ operation.
  2. Get the container PID from the state (and maybe the process
    namespace that PID is from 1).
  3. Find a procfs mount for the process namespace listed in the state
    JSON 1).

The namespace paths would be from /proc/{pid}/ns/…, and the
cgroupsPath would be from /proc/{pid}/cgroup (any particular cgroup in
that list?).

Any ideas about ‘root’?

 Subject: Linux: Adding the PID namespace inode to state JSON
 Date: Wed, 30 Dec 2015 21:34:57 -0800
 Message-ID: <20151231053457.GG3680@odin.tremily.us>

@crosbymichael
Copy link
Member

LGTM after travis is happy

@vishh
Copy link
Contributor Author

vishh commented Apr 19, 2016

@wking We need blessed cookbook for the Spec.

Signed-off-by: Vishnu kannan <vishnuk@google.com>
@wking
Copy link
Contributor

wking commented Apr 19, 2016

On Tue, Apr 19, 2016 at 03:20:51PM -0700, Vish Kannan wrote:

@wking We need blessed cookbook for the Spec.

Sounds good to me. And that can certainly happen in a separate
thread/issue/PR if folks want. But I think it makes sense to back up
the “can be implemented…” claim with explicit “… and here's how …”
directions in this PR. There aren't many missing pieces in 1, so it
shouldn't take that much work to clear them up.

@crosbymichael
Copy link
Member

We can work on that stuff later, we just need to get the spec finalized and in good shape before we start talking about how ppl should implement something

@wking
Copy link
Contributor

wking commented Apr 19, 2016

On Tue, Apr 19, 2016 at 04:09:13PM -0700, Michael Crosby wrote:

We can work on that stuff later, we just need to get the spec
finalized and in good shape before we start talking about how ppl
should implement something

Agreed, I just think “in good shape” includes exec-like behavior. To
avoid reducing functionality with this PR, I think we need to also
fill in the gaps to make ‘exec’ emulation possible.

For example, making ‘root’ optional 1 would be one way to address a
question from 2. If folks have alternative approaches for handling
that question (supported by the current spec?), that seems like the
sort of thing we want hashed out before we remove the current ‘exec’
feature.

 Subject: Dropping the rootfs requirement and restoring arbitrary bundle content
 Date: Wed, 26 Aug 2015 12:54:47 -0700
 Message-ID: <20150826195447.GX21585@odin.tremily.us>

@mrunalp
Copy link
Contributor

mrunalp commented Apr 20, 2016

@wking I think we can handle examples/cookbook etc. after this PR. To answer your question about root, it isn't used in exec if there is a mount namespace.

@mrunalp
Copy link
Contributor

mrunalp commented Apr 20, 2016

LGTM

@mrunalp mrunalp merged commit 0982071 into opencontainers:master Apr 20, 2016
@wking wking mentioned this pull request Apr 20, 2016
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Apr 20, 2016
Spun off from discussion here [1].  There seemed to be consensus that
we need something like this but that it should be it's own pull
request [2,3,4].

[1]: opencontainers#388 (comment)
[2]: opencontainers#388 (comment)
[3]: opencontainers#388 (comment)
[4]: opencontainers#388 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Apr 20, 2016
Spun off from discussion here [1].  There seemed to be consensus that
we need something like this but that it should be its own pull request
[2,3,4].

[1]: opencontainers#388 (comment)
[2]: opencontainers#388 (comment)
[3]: opencontainers#388 (comment)
[4]: opencontainers#388 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Apr 20, 2016
Spun off from discussion here [1].  There seemed to be consensus that
we need something like this but that it should be its own pull request
[2,3,4].

[1]: opencontainers#388 (comment)
[2]: opencontainers#388 (comment)
[3]: opencontainers#388 (comment)
[4]: opencontainers#388 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request May 13, 2016
Addressed by 7117ede (Expand on the definition of our ops,
2015-10-13, opencontainers#225), although there has been additional discussion in
a7a366b (Remove exec from required runtime functionalities,
2016-04-19, opencontainers#388) and 0430aaf (Split create and start, 2016-04-01,
opencontainers#384).

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request May 15, 2016
# digest/hashing target

Most of this has spun off with [1], and I haven't heard of anyone
talking about verifying the on-disk filesystem in a while.  My
personal take is on-disk verification doesn't add much over serialized
verification unless you have a local attacker (or unreliable disk),
and you'll need some careful threat modeling if you want to do
anything productive about the local attacker case.  For some more
on-disk verification discussion, see the thread starting with [2].

# distributable-format target

This spun off with [1].

# lifecycle target

I think this is resolved since 7713efc (Add lifecycle for containers,
2015-10-22, opencontainers#231), which was committed on the same day as the ROADMAP
entry (4859f6d, Add initial roadmap, 2015-10-22, opencontainers#230).

# container-action target

Addressed by 7117ede (Expand on the definition of our ops,
2015-10-13, opencontainers#225), although there has been additional discussion in
a7a366b (Remove exec from required runtime functionalities,
2016-04-19, opencontainers#388) and 0430aaf (Split create and start, 2016-04-01,
opencontainers#384).

# validation and testing targets

Validation is partly covered by cdcabde (schema: JSON Schema and
validator for `config.json`, 2016-01-19, opencontainers#313) and subequent JSON
Schema work.  The remainder of these targets are handled by ocitools
[3].

# printable/compiled-spec target

The bulk of this was addressed by 4ee036f (*: printable documents,
2015-12-09, opencontainers#263).  Any remaining polishing of that workflow seems
like a GitHub-issue thing and not a ROADMAP thing.  And publishing
these to opencontainers.org certainly seems like it's outside the
scope of this repository (although I think that such publishing is a
good idea).

[1]: https://github.com/opencontainers/image-spec
[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ
     Subject: OCI Bundle Digests Summary
     Date: Wed, 14 Oct 2015 17:09:15 +0000
     Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com>
[3]: https://github.com/opencontainers/ocitools

Signed-off-by: W. Trevor King <wking@tremily.us>
Mashimiao pushed a commit to Mashimiao/specs that referenced this pull request Aug 19, 2016
# digest/hashing target

Most of this has spun off with [1], and I haven't heard of anyone
talking about verifying the on-disk filesystem in a while.  My
personal take is on-disk verification doesn't add much over serialized
verification unless you have a local attacker (or unreliable disk),
and you'll need some careful threat modeling if you want to do
anything productive about the local attacker case.  For some more
on-disk verification discussion, see the thread starting with [2].

# distributable-format target

This spun off with [1].

# lifecycle target

I think this is resolved since 7713efc (Add lifecycle for containers,
2015-10-22, opencontainers#231), which was committed on the same day as the ROADMAP
entry (4859f6d, Add initial roadmap, 2015-10-22, opencontainers#230).

# container-action target

Addressed by 7117ede (Expand on the definition of our ops,
2015-10-13, opencontainers#225), although there has been additional discussion in
a7a366b (Remove exec from required runtime functionalities,
2016-04-19, opencontainers#388) and 0430aaf (Split create and start, 2016-04-01,
opencontainers#384).

# validation and testing targets

Validation is partly covered by cdcabde (schema: JSON Schema and
validator for `config.json`, 2016-01-19, opencontainers#313) and subequent JSON
Schema work.  The remainder of these targets are handled by ocitools
[3].

# printable/compiled-spec target

The bulk of this was addressed by 4ee036f (*: printable documents,
2015-12-09, opencontainers#263).  Any remaining polishing of that workflow seems
like a GitHub-issue thing and not a ROADMAP thing.  And publishing
these to opencontainers.org certainly seems like it's outside the
scope of this repository (although I think that such publishing is a
good idea).

[1]: https://github.com/opencontainers/image-spec
[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ
     Subject: OCI Bundle Digests Summary
     Date: Wed, 14 Oct 2015 17:09:15 +0000
     Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com>
[3]: https://github.com/opencontainers/ocitools

Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants