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 |
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).
dfr
force-pushed
the
freebsd-spec
branch
2 times, most recently
from
051877a to
bb9e6b2
Compare
There was a problem hiding this comment.
I've implemented this for runj in samuelkarp/runj#63, so from my perspective this now LGTM.
|
Needs rebase |
I will take care of that today. I also have small changes to add |
dfr
force-pushed
the
freebsd-spec
branch
2 times, most recently
from
e992b1b to
61f918b
Compare
|
Ah okay, I was going off the discussion we had a few weeks ago, I didn't notice that we'd resolved the outstanding issues. I'm okay to merge this then. |
| * **`ip4`** _(string, OPTIONAL)_ - control the availability of IPv4 addresses. | ||
| Set to "inherit" to allow access to host (or parent container) addresses or set to "disable" to stop use of IPv4 entirely. This is typically left unset when **`vnet`** is used (see below). | ||
| * **`ip4Addr`** _(array of strings, OPTIONAL)_ - restrict the set of IPv4 addresses which the container can use. These addresses should be in numeric form (e.g. `"10.11.12.13"`). This can be used to allow restricted use of the host network. A common pattern with FreeBSD jails is to add alias addresses to a loopback interface and restrict each jail to a subset of addresses. | ||
| * **`ip6`** _(string, OPTIONAL)_ - control the availability of IPv6 addresses. | ||
| Set to "inherit" to allow access to host (or parent container) addresses or set to "disable" to stop use of IPv6 entirely. This is typically left unset when **`vnet`** is used (see below). | ||
| * **`ip6Addr`** _(array of strings, OPTIONAL)_ - restrict the set of IPv6 addresses which the container can use. These addresses should be in numeric form (e.g. `"fd10::11:12:13"`). This can be used to allow restricted use of the host network. A common pattern with FreeBSD jails is to add alias addresses to a loopback interface and restrict each jail to a subset of addresses. | ||
| * **`vnet`** _(string, OPTIONAL)_ - control the vnet used for this container. | ||
| The value can be "new" which causes a new vnet to be created for the container or "inherit" which shares the vnet for the parent container (or host if there is no parent). | ||
| * **`interface`** _(string, OPTIONAL)_ A network interface to add the container's IP addresses (**`ip4Addr`** and **`ip6Addr`**) to. An alias for each address will be added to the interface when the container is created, and will be removed from the interface after the container is stopped. This is typically used when **`vnet`** is not set. | ||
| * **`vnetInterfaces`** _(array of strings, OPTIONAL)_ - a set of network interfaces which are added to the container's vnet during its lifetime. |
There was a problem hiding this comment.
I get this proposal has already been implemented and so there is fairly limited scope for changes, but it feels like these should be grouped in a network object (and similarly ipv4 and ipv6 should also be objects containing the type and address):
{
"freebsd": {
"jail": {
"network": {
"ipv4": {
"type": "new",
"addr": "10.10.10.1"
},
"vnet": "new"
}
}
}
}or something similar.
There was a problem hiding this comment.
I respectfully disagree here -- as far as I understand, the layout mirrors that of jail settings, and improving upon it (in this case by encapsulating some options under "network") is IMO not should be a goal here. Direct 1:1 is better in most cases.
There was a problem hiding this comment.
The table below implies that "ip4Addr" is a sub-option of "ipv4" in the jail config, we can't really represent that in JSON (well, you can use "ip4.addr" as a key and Go does support that -- we have an example of this in image-spec -- but it can lead to issues with other tools) so I figured that having an object containing both would be closer.
But as I said, given this has already been implemented it's probably a bit too late for this discussion anyway.
There was a problem hiding this comment.
As a meta point, I don't think existing PoC code should preclude making changes here, if they make sense, especially as now (before merge/release) would be the ideal time to make them if we need or want to.
There was a problem hiding this comment.
runj has POC code in both styles anyway: https://github.com/samuelkarp/runj/blob/dffa97ef2be9db79679ed218d109e5f97027de51/runtimespec/config.go#L184-L234
There was a problem hiding this comment.
The implementations are relatively simple and it won't be a lot of effort to change. I'm weakly against changing the schema but that's mostly due to a concern that we waste too much time getting consensus on a better schema.
There was a problem hiding this comment.
I think the version in runj that @samuelkarp pointed to seems quite reasonable to me, and it has the benefit of already being implemented. @kolyshkin / @dfr would you be happy with that version?
If either of you have reservations, I'm okay with taking this PR as-is. Ultimately it's up to FreeBSD runtimes to deal with these configs and if you folks are fine with it then it's really not up to me whether it should be changed.
This uses FreeBSD jails to implement container isolation. Signed-off-by: Doug Rabson <[email protected]>
|
... merging with open/active discussion and only two approvals on a fairly large addition seems kind of premature? 🤷 |
|
I was hoping to get more information about whether the runj approach was acceptable to @dfr but as I said, I don't have a strong opinion on it. I'm a bit more confused why there was a perceived rush to merge this for 1.3 (we want 1.3 for runc 1.4 -- though I also don't think this should be a hard requirement -- but the FreeBSD stuff is not really relevant for that either). At the end of the day, I'm fine with the merged version. |
|
Sorry, I am a little late to this part of the discussion and failed to reply before this was merged. I have been thinking a lot on the suggested structure which splits out the ip4 and ip6 parameters into sub-objects. I don't think this adds much in readability - in particular, the way it moves the namespace parameters (e.g. The underlying jail parameter set has no sub-structure - its just a list of key/value pairs where some of the keys names happen to have "." characters in them, e.g. Personally, I am happy with the merged version as it represents the consensus approach for our working group and has benefitted from this review process. If there are any concerns regarding the open discussion points, perhaps this can be addressed in followup pull requests if there is time before 1.3. |
|
Sorry for the rush, feel free to open follow-up issues (or PRs) for remaining concerns 🙇 |
|
@dfr Thanks, in that case I'm fine with just keeping it as-is. |
12 participants
This uses FreeBSD jails to implement container isolation.