Releases the consolidated chart as ingress 1.0.0-rc1.
Removes most existing ingress chart content and moves existing kong content under the ingress directory. Consolidates some ingress documentation into the kong files.
Removes the kong chart aside from its historical changelog.
This will release an RC chart version from the release branch. main will remain as-is for now. When we are ready to finalize the release, we will cut an old version release branch from the tip of main before merging this into main.
Special notes for your reviewer:
Releasing as ingress creates documentation challenges
Although we can effectively replace the ingress chart contents with the kong-derived consolidated chart without losing git history, we will probably break a lot of links. Because the kong chart had been around for longer and held most of the chart complexity, both internal and external docs contain a lot of references to it that would no longer work (Github doesn't provide a redirect mechanism, though we could maybe symlink the old locations to the new paths under ingress/).
I've attempted a basic pass to update paths in the readme, FAQ, and upgrade guide, but probably haven't caught everything. There are some cases where links shouldn't change that frustrate a naive search and replace.
I don't know how we should handle the changelog if we release this as ingress. It's put in a strange position where the kong history is generally relevant and the ingress 0.x history mostly isn't, but the changes go into the ingress sequence after 0.x. The upgrade guide has a minor version of this problem where the version number sequence jumps backwards and would eventually overlap (we only ever had it for kong).
While we still need to handle ingress files if we go the other way around, there are fewer of them and fewer references to them, so I'd recommend reconsidering how attached we are to using a specific name for this.
Revised file structure
I originally planned to use symlinks instead of git mv for templates, but I think this would probably be more confusing than it's worth. The only advantage of symlinks would be that we could backport some changes to kong 2.x more easily, since the filenames would be the same and would cherry-pick successfully. Moving them means we'd need to either manually redo changes or hack patches to use different paths before applying them.
The Github UX for symlinks is unfortunately quite limited, and will just show you a brief summary of the link target location (e.g. https://github.com/rainest/charts-citest/blob/main/charts/ingress/templates), and linked directories do not allow browsing to their contents under the link path. They wouldn't, as such, do much to resolve broken links from elsewhere.
What this PR does / why we need it:
Releases the consolidated chart as
ingress
1.0.0-rc1.Removes most existing
ingress
chart content and moves existingkong
content under theingress
directory. Consolidates someingress
documentation into thekong
files.Removes the
kong
chart aside from its historical changelog.This will release an RC chart version from the release branch.
main
will remain as-is for now. When we are ready to finalize the release, we will cut an old version release branch from the tip ofmain
before merging this intomain
.Special notes for your reviewer:
Releasing as ingress creates documentation challenges
Although we can effectively replace the
ingress
chart contents with thekong
-derived consolidated chart without losing git history, we will probably break a lot of links. Because thekong
chart had been around for longer and held most of the chart complexity, both internal and external docs contain a lot of references to it that would no longer work (Github doesn't provide a redirect mechanism, though we could maybe symlink the old locations to the new paths underingress/
).I've attempted a basic pass to update paths in the readme, FAQ, and upgrade guide, but probably haven't caught everything. There are some cases where links shouldn't change that frustrate a naive search and replace.
I don't know how we should handle the changelog if we release this as
ingress
. It's put in a strange position where thekong
history is generally relevant and theingress
0.x history mostly isn't, but the changes go into theingress
sequence after 0.x. The upgrade guide has a minor version of this problem where the version number sequence jumps backwards and would eventually overlap (we only ever had it forkong
).While we still need to handle
ingress
files if we go the other way around, there are fewer of them and fewer references to them, so I'd recommend reconsidering how attached we are to using a specific name for this.Revised file structure
I originally planned to use symlinks instead of
git mv
for templates, but I think this would probably be more confusing than it's worth. The only advantage of symlinks would be that we could backport some changes tokong
2.x more easily, since the filenames would be the same and would cherry-pick successfully. Moving them means we'd need to either manually redo changes or hack patches to use different paths before applying them.The Github UX for symlinks is unfortunately quite limited, and will just show you a brief summary of the link target location (e.g. https://github.com/rainest/charts-citest/blob/main/charts/ingress/templates), and linked directories do not allow browsing to their contents under the link path. They wouldn't, as such, do much to resolve broken links from elsewhere.