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

Is PORTS field neccessary for oci specs? #178

Closed
ChengTiesheng opened this issue Sep 11, 2015 · 6 comments
Closed

Is PORTS field neccessary for oci specs? #178

ChengTiesheng opened this issue Sep 11, 2015 · 6 comments

Comments

@ChengTiesheng
Copy link
Contributor

The container will listen on the specified network ports at runtime for the purpose of interconnecting, as a result, I think exposed port is important for the container runtime. Is it neccessary to add PORTS field for the specs. Maybe it is appropriate to add Port struct in runtime_config.go.

@gao-feng
Copy link
Contributor

I think this job should be done by upper program such as Docker, Hyper etc. upper program should manage network itself.

@vbatts
Copy link
Member

vbatts commented Sep 11, 2015

That is a higher level. At best there might could be interface level requests, but not port level.

@vbatts vbatts closed this as completed Sep 11, 2015
@luebken
Copy link

luebken commented Mar 17, 2016

Would you mind elaborating why they shouldn't be on container level?

Both Docker and appc have means of doing so. And I find it reasonable since it gives means of declaring the ports a container listens on.

@wking
Copy link
Contributor

wking commented Mar 17, 2016

On Thu, Mar 17, 2016 at 08:29:13AM -0700, Matthias Lübken wrote:

Would you mind elaborating why they shouldn't be on container level?

Networking is out-of-scope for the OCI runtime spec. For more
discussion and suggestions for plugging in a network manager via
hooks, see [1,2]. If you feel inspired to write up a wiki entry
covering that, and a link from this repo to the wiki discussion, I
expect it would get merged [3](but I'm not a maintainer).

 Subject: Do we have any plan for network and storage specs?
 Date: Fri, 14 Aug 2015 02:36:15 -0700 (PDT)
 Message-Id: <c056925e-6ecf-4457-8c16-7ab34d279604@opencontainers.org>

 Subject: no vNIC in the container, what is a good default .json template?
 Date: Thu, 10 Dec 2015 12:18:07 -0800 (PST)
 Message-Id: <acbb4587-8d80-452a-8908-446f14a5107c@opencontainers.org>

@luebken
Copy link

luebken commented Mar 24, 2016

@wking thanks for the pointers. But I'm not so much into the topic that I would feel ready for writing a wiki entry.

I do understand the tension not introducing more areas into this spec like networking. At the same time I feel that declaring what ports a container is listening on would be quite beneficial. And this is independent of the underlying network solution.

@vbatts what do you mean by "interface level" in

That is a higher level. At best there might could be interface level requests, but not port level.

@wking
Copy link
Contributor

wking commented Mar 24, 2016

On Thu, Mar 24, 2016 at 05:54:31AM -0700, Matthias Lübken wrote:

At the same time I feel that declaring what ports a container is
listening on would be quite beneficial.

The runtime won't care about them, but they may be interesting to
higher-level tooling. With annotations (#331, v0.4.0), you can setup:

{
"annotations": {
"ports": "1,2,3"
},

}

in your config.json, although we'd need to land an opaque type 1 to
support something like:

{
"annotations": {
"some-networking-spec": {
"version": "1.2.3",
"ports": [80, 443]
}
},

}

with the bundled Go types.

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

No branches or pull requests

5 participants