Windows targets for 1.0?

[wking]

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.

[lowenna]

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.

[wking]

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

[lowenna]

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.

[wking]

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?

[lowenna]

@wking - I'll leave that for others to debate.

[wking]

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

[lowenna]

Yes, I am fully aware of rules around addition and deprecation...

[tianon]

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?

[wking]

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

[tianon]

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.

[tianon]

To expand a bit, I see essentially three options here:

1. rush review the new Windows bits and cram them into the overdue 1.0 (hoping/assuming that they're good)

2. remove Windows from 1.0 entirely (obviously not a great outcome)

3. find some kind of middle ground where Windows is included, but without the same strict next-version compatibility requirements (a "preview" of Windows-in-the-spec)

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.

[lowenna]

The complete list of PRs with additions for Windows are: #801, #814, #815, #816, #817 and #818.

The current set of unmerged PRs for changes for Windows that are not additions are: #820 and #821. I'll look through the remainder of the spec to see if there are any other discrepancies.

[sunjayBhatia]

Another addition is: #828 to include LayerFolders