Add FreeBSD as a platform #1286
Conversation
dfr
requested review from
AkihiroSuda,
crosbymichael,
cyphar,
dqminh,
giuseppe,
hqhq,
kolyshkin,
mrunalp,
thaJeztah,
tianon and
utam0k
as code owners
|
Cc @samuelkarp |
config-freebsd.md
Outdated
| "devices": [ | ||
| { | ||
| "path": "pf", | ||
| "mode": "0700" |
There was a problem hiding this comment.
I guess it has to be a string because JSON representation of an octal "0700" as a number would be 448 in decimalised JSON...
There was a problem hiding this comment.
This is a string which is interpreted as in chmod(1) which supports octal numeric modes as well as symbolic. I will fix the text to make this a little clearer.
There was a problem hiding this comment.
we already have a fileMode that is specified in defs-linux.json, could we move it to defs.json and use it here too?
I know the string representation looks better, but we don't have to deal with parsing and usually the OCI spec file is not written by a human
There was a problem hiding this comment.
This is a very good point. In this case, the parsing is handled by the devfs(8) system utility but that doesn't mean that this specification needs to allow anything more than a simple three digit octal number. I will rearrange things to share the definition of fileMode with config-linux.json and change this field to use that.
| ] | ||
| ``` | ||
|
|
||
| ## <a name="configFreeBSDJail" />Jail |
There was a problem hiding this comment.
This section feels to me more like documentation for an existing implementation than specification from which a new compatible implementation could be implemented. 🤔
Are there specific features of FreeBSD that could be explicitly named here to help connect these things more strongly? Are there any places here where SHOULD or MUST language would be appropriate?
There was a problem hiding this comment.
This section is informational and is intended as a guide for readers familiar with FreeBSD jails to help them understand the mapping from the FreeBSD OCI config settings to the corresponding jail.
Since this proposal only covers the use of FreeBSD jails to implement OCI containers, there is very little freedom for implementors. The text following the table would benefit from using SHOULD/MUST language.
There was a problem hiding this comment.
We could remove this section since it mostly just helps implementers familiar with FreeBSD jails to understand the mapping from runtime config.
I'm happy to remove it if others feel that it isn't appropriate here but otherwise I do think it is somewhat useful for implementers.
dfr
force-pushed
the
freebsd-spec
branch
2 times, most recently
from
99dd807 to
ee03193
Compare
|
Fixed the type of FreeBSDDevice.Mode and fixed a typo in the json mapping for FreeBSDJail.SysVShm. |
|
I took another pass over this today and made a couple of minor changes. I think the only current open question is whether the Does anyone else have comments or suggestions for the FreeBSD runtime extension? What should our next steps be to make this acceptable for the runtime spec? |
|
@dfr we attended the developer meeting but it was Juneteenth and the attendance was relatively low. They suggested that you ping Tianon and Sam to ask for them to review it. If that doesn't work, we can try to attend the dev call again. |
Thanks! I will check out your comment on the PR but my internet connection is flaky at the moment which is slowing me down a bit (hopefully that will be fixed over the weekend). |
There was a problem hiding this comment.
This looks pretty decent to me, although admittedly I'm not super familiar with FreeBSD / jails internals.
If we're not in a hurry to merge, I'd love to wait until @samuelkarp has a chance to review too, but if we've got something urgent that needs this, I think it's probably in a reasonable state (and hopefully he doesn't disagree).
| * **`host`** _(string, OPTIONAL)_ - allow overriding hostname, domainname, hostuuid and hostid. | ||
| The value can be "new" which allows these values to be overridden in the container or "inherit" to use the host values (or parent container values). If set to "new", the values for hostname and domainname are taken from the base config, if present. | ||
| * **`ip4`** _(string, OPTIONAL)_ - control the availability of IPv4 addresses. | ||
| This is typically left unset if the container has a vnet, set to "inherit" to allow access to host (or parent container) addresses or set to "disable" to stop use of IPv4 entirely. |
There was a problem hiding this comment.
Is it reasonable to also set this explicitly to "vnet", or is that intentionally not supported? (is there some other way to explicitly ask for that "unset" behavior?)
I guess that's "vnet": "new"? or have I mixed things?
There was a problem hiding this comment.
Allowed values for "ip4" are "inherit", "new" or "disable". The interactions between vnet and ip4 are not clearly documented but by experimentation, I discovered that if "vnet" is set to "new", then "ip4" must be left unset, otherwise we get an EINVAL error.
This uses FreeBSD jails to implement container isolation. Signed-off-by: Doug Rabson <[email protected]>
This uses FreeBSD jails to implement container isolation.