Windows targets for 1.0? #817
Comments
|
These fields (and more) are currently passed out of band in docker (see link to specific code) for some time (most since TP3 timeframe of Windows Server 2016). We are pushing to get these in to v1.0 so that Windows can be spec compliant. They are all required fields to run containers on Windows. |
|
So “we see them as 1.0 blockers” and “the properties are well cooked”.
Do you feel they are sufficient for compliance testing? It would make
me happier (although I'm not a maintainer, so my happiness is not
relevant ;) if runtime-tools was capabable of doing some Windows
compliance testing. But like Linux and #746, I expect we only have
time for an eyeball assessment of “we can write tests based on this”
on most properties.
On Fri, May 12, 2017 at 03:41:22PM -0700, John Howard wrote:
They are all required fields to run containers on Windows.
I don't see REQUIRED in any of them, so you probably mean “necessary
for most useful containers on Windows”. That makes life a bit easier
though, since you could cut 1.0 without a particular OPTIONAL
property, continue to use it as an extension [1], and then land the
backing spec in 1.1. That way everything works, and just means:
* 1.0 compliance testing is less meaningful on Windows, and
* 1.0 configs are more vulnerable to interop issues between different
Windows runtimes (which is probably not a big deal if there is only
one Windows runtime.
[1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/config.md#extensibility
|
|
By required, I meant your latter "necessary for most useful containers on Windows", the reality being "necessary for ALL useful containers on Windows". Some fields will not be optional - particularly layer folders (PR not open yet) and some Hyper-V isolation specific fields. |
|
On Fri, May 12, 2017 at 03:56:17PM -0700, John Howard wrote:
Some fields will not be optional - particularly layer folders (PR
not open yet) and some Hyper-V isolation specific fields.
Is landing these now, after rc5, with #726 down to “final sanity
check” really viable? They have to get through review, and
post-landing I'd expect at least a week to collect any public feedback
from folks less involved than maintainers. Do you expect that to get
done (with some PRs still unsubmitted) in under a month? Is slipping
the big shifts to 1.1 a big deal?
|
|
@wking - I'll leave that for others to debate. |
|
On Fri, May 12, 2017 at 04:04:36PM -0700, John Howard wrote:
@wking - I'll leave that for others to debate.
This is fine (and I have no stake in this either way), but my gut
tells me that not all of this is going to land in time for 1.0 unless
things get rushed in or the 1.0 vote goes out in July+. So
maintainers and Windows folks should figure out what they *do* need to
land for 1.0. It doesn't have to be you, but someone from Windows
should make sure this happens.
For example, if you plan on dropping a property, you have to drop it
now. New properties can be added in 1.1, but dropping a 1.0 property
requires a bump to 2.0 [1]. The same goes for adding additional
restrictions. If you allow a given value in 1.0, you have to go to
2.0 to forbid that value.
[1]: https://github.com/opencontainers/runtime-spec/blob/ce6011c65aa1874ca85f73fc2f5cfba82a4070df/config.md#specification-version
|
|
Yes, I am fully aware of rules around addition and deprecation... |
|
What about giving Windows "preview" status in 1.0 (thus giving more time for review while also getting folks testing some of it), and making it official and fully-supported in 1.1? |
|
On Fri, May 12, 2017 at 10:57:40PM -0700, Tianon Gravi wrote:
What about giving Windows "preview" status in 1.0…
Does that mean “excepted from SemVer”? If so, it may require language
poking a hole in [1].
[1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/config.md#specification-version
|
|
Hoping to gauge maintainer / Windows folks reactions to the idea of making Windows "preview only" for 1.0 before getting buried in the semantics of what exactly changes in the repos/language as a result, thanks. |
|
To expand a bit, I see essentially three options here:
If we go with option 3, then best case next release we simply ratify what we'd already released previously. Worst case we've left ourselves room to escape hatch the Windows bits without going full 2.0. |
|
Another addition is: #828 to include |
|
Given @jhowardmsft and @sunjayBhatia's work, I think we can safely close this. Windows is in good shape for 1.0 (with only one or two PRs remaining to review). |
|
On Wed, May 24, 2017 at 08:28:04AM -0700, Tianon Gravi wrote:
Windows is in good shape for 1.0 (with only one or two PRs remaining
to review).
One of those remaining PRs is #849, which leaves me jumpy about the
stability of the recent additions. And there are still no
runtime-oriented Windows requirements in config-windows.md except for
[1]. That means a runtime can still ignore all properties except for
windows.hyperv and still be “compliant” [2]. So I'd still consider a
preview status for Windows and 1.0,
[1]: https://github.com/opencontainers/runtime-spec/blame/2ec18c02474dd49ce20aa30236959a8a80763042/config-windows.md#L145
[2]: https://github.com/opencontainers/runtime-spec/blame/2ec18c02474dd49ce20aa30236959a8a80763042/spec.md#L41
|
Can somebody from Windows comment on how they see #801, #814, #815, and #816 fitting into 1.0? Are these 1.0 blockers? There have been quite a few changes so far since rc5 (and maybe more in #746), but for the most part they've been minor polishing and shifting around well-known properties (e.g. #789). These feel like larger changes to me, and I'm concerned about pushing them into 1.0 before they've had time to cook.
Do you see these PRs as 1.0 blockers? As something you're staging here for post-1.0? Have they already been cooking somewhere else, and therefore maybe needing a shorter cook-time in OCI?
Even if the properties and docs have been cooking for a while somewhere else, I think spec language also needs cooking. Is there enough here for compliance testing based on RFC 2119 and our definition of “compliant”?
Ping @jhowardmsft, @darrenstahlmsft, @RobDolinMS.
The text was updated successfully, but these errors were encountered: