RFC: Change the lifecycle spec to support Windows. #27
Conversation
Signed-off-by: Micah Young <[email protected]>
micahyoung
changed the title
micahyoung
changed the title
|
|
||
| This RFC proposes adding official Windows support to the lifecycle which can be optionally used by all platforms and buildpacks. There will be a new Windows-specific, distributable lifecycle artifact containing cross-compiled versions of lifecycle commands. Buildpacks can be either Windows-specific or cross-platform by following Windows conventions. Windows-specific builder images can be created based on the lifecycle and buildpacks. | ||
|
|
||
| This introduces new functionality that is relevant to all personas that interact with buildpacks. This has no impact on existing users. |
There was a problem hiding this comment.
despite this, i think any spec changes should probably enter as extensions, especially if there's a concern that the Docker for Windows is less than stable.
There was a problem hiding this comment.
Thank Joe. I may have undersold the current stability of Docker for Windows - both the Desktop and Server container runtimes are far along - Docker Desktop got Windows containers in early 2018 and but Windows Server has had them since 2017. At this point, Pivotal PKS, Azure AKS and Google GKE have Windows Workers for Kubernetes in various Beta flavors but they'll be GA "any day now" and as far as I know, all of these soon-to-be-GA IaaS k8s are built against the same APIs that we'll depend on - the Docker client APIs and Windows OCI image format.
My caveat here in the RFC was mainly to point out this historical context and how Windows Docker containers are only now where Linux Docker containers have been for some time and so might possibly see some last minute changes. The major APIs we need are well defined though and Windows and Linux should very soon be equally stable.
As for having Windows defined in extensions, I'll admit I'm new to the RFC concepts but I'm wondering if there's a risk of having Windows defined just as an extension may lead to more Linux-only design choices that might, when it's time to implement them for Windows, require less elegant solutions or just wouldn't possible without an upstream change. This might mean reworking already-implemented specs and features or needing to feature-flag them off on Windows.
I feel like we've seen some examples of this in the current spec. One that popped up was relying on Linux shebang kernel support to enable scripts and binaries with the same file names - it's a handy feature for Linux but doesn't work well for Windows platforms which instead need explicit suffixes to determine whether they're executable or scripts. I'm not exactly sure what a cross-OS approach would have been but it certainly has lead us to need to come up with a new approach just for Windows, without the benefit of a single solution for both OSes.
I definitely wouldn't want Windows concerns to slow down RFC ideation but to me, it feels safer to resolve any issues well before spec and implementation happens or to explicitly agree to set aside Windows concerns when needed. This may even minimize the need for any Windows-specific spec concerns in the first place.
But I'd like hear other thoughts and concerns though.
There was a problem hiding this comment.
Not trying to jump the gun but I opened a spec PR with one potential approach to defining Windows within the current specs. I'm hoping this accounts for everything that needs to be defined but I'm still open to putting these wherever makes the most sense.
There was a problem hiding this comment.
Sorry for the noise. Struggling with the commenting flow
[resolves #49] Signed-off-by: Ben Hale <[email protected]>
[resolves buildpacks#49] Signed-off-by: Ben Hale <[email protected]>
Readable
Work-in-progress spec changes are here and subject to change
buildpacks/spec@master...greenhouse-org:windows-lifecycle