Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft: Remove Windows Containers support #311

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 97 additions & 0 deletions text/0000-remove-windows-containers-support.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
# Meta
[meta]: #meta
- Name: Remove Windows Containers Support
- Start Date: 2024-04-11
- Author(s): aidan.delaney
- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded -->
- RFC Pull Request: (leave blank)
- CNB Pull Request: (leave blank)
- CNB Issue: (leave blank)
- Supersedes: "N/A"

# Summary
[summary]: #summary

Retain Windows Containers support in the buildpacks specification, but remove Windows Containers support from `lifecycle`, `pack` CLI, and documentation.

# Definitions
[definitions]: #definitions

Make a list of the definitions that may be useful for those reviewing. Include phrases and words that buildpack authors or other interested parties may not be familiar with.

* [Windows Containers](https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/): Containers derived from Windows Server Containers. For example: `mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022`

# Motivation
[motivation]: #motivation

- There are no known users of Windows Container support within the buildpacks ecosystem.
- Supporting Windows Containers is straightforward at a specification level. However, the CNB project has neither the time nor the expertise to continue to support Windows Containers in our tooling.
- Removing Windows Container support from CNB tooling will speed up development, simplify testing and impact no existing users.
- Establish platform parity between `pack` and `kpack`. `kpack` has never supported building Windows Containers.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kpack actually does support building windows containers (buildpacks-community/kpack#546), albeit in a slightly more limited capacity. There is an open discussion on the kpack side to remove windows support (buildpacks-community/kpack#1366)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I see it's difficult to get community feedback on this as, I suspect, there are no kpack users who build Windows containers.


# What it is
[what-it-is]: #what-it-is

- We want to remove Windows Containers related documentation, but clearly state that the specification is platform neutral.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How hard will it be to make a platform neutral specification format, i.e. POSIX vs. windows?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're hoping to maintain the status-quo in the specification where we currently state things like

It will be difficult to keep in mind the POSIX/Windows differences when changing the specification. However, I suspect this will be no-more difficult than currently as we have no known Windows containers users.

- Remove Windows Containers support from `pack`, but retain the Windows platform release of the `pack` CLI.
* this ensures `pack` users can still invoke `pack` on a Command or Power Shell console
- Remove Windows Containers support from `lifecycle`. Lifecycle can remove the Windows platform release as it will then be guaranteed to run on a Linux-based container.

# How it Works
[how-it-works]: #how-it-works


# Migration
[migration]: #migration

Teams that require Windows Container support will have to

* continue to use the last release of `pack` that supports Windows Containers,
* fork `pack` and `lifecycle` to maintain Windows Containers support, or
* adopt alternative tooling that supports Windows Containers.

# Drawbacks
[drawbacks]: #drawbacks

Windows Containers support is well tested within `pack`. Removing support for Windows Containers removes a unique selling point of the `pack` CLI and `lifecycle`

# Alternatives
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This came up in the WG today. Would we want to tie this to a spec change and just remove it all together from the spec?

[alternatives]: #alternatives

- We have discussed platform support with `pack` users. There are no `pack` users who want to maintain Windows Container support. Should engineering effort become available to help with development and maintenance, then this proposal can be dropped.

# Prior Art
[prior-art]: #prior-art

N/A

# Unresolved Questions
[unresolved-questions]: #unresolved-questions

- We have made outreach efforts to CNB users to survey requirements of Windows Container support. We have found no users. The number of CNB users that require Windows Container support is still an open question.

# Spec. Changes (OPTIONAL)
[spec-changes]: #spec-changes

This proposal requires no specification changes.

# History
[history]: #history

<!--
## Amended
### Meta
[meta-1]: #meta-1
- Name: (fill in the amendment name: Variable Rename)
- Start Date: (fill in today's date: YYYY-MM-DD)
- Author(s): (Github usernames)
- Amendment Pull Request: (leave blank)

### Summary

A brief description of the changes.

### Motivation

Why was this amendment necessary?
--->
Loading