Minecraft Operator 1.0 Roadmap
Opened this issue · 2 comments
Roadmap
Please discuss below, this is very much a living document.
Currently there is a single CRD for Minecraft. This should be split into two CRDs, Minecraft for server deployment, and MinecraftNetwork for internal routing/external access.
Minecraft
- Revamp the Minecraft CRD
- Configuration should be a subset of existing Minecraft CRD, with as many parameters trimmed as possible (through elimination of redundant or error-causing parameters and more intelligent defaulting). Basically just make it a bit higher level.
- Add backup scheduling
- Add recovery mechanisms
- Add more information to status
- Add ability to scale down servers
MinecraftNetwork
- Create MinecraftNetwork CRD
- Deploy Bungeecord with k8s-native plugins
- Expose router on a NodePort for external access
- Report as much networking info as possible in status
- Use selector to build network of Minecraft servers
- Should deploy a default, minimal lobby server (possibly with version/mod compatibility plugins)
Packaging
- Addition of necessary metadata for Operator Lifecycle Manager (OLM)
- Submission to operatorhub.io
Stretch Goals
- Automated scale up/down of servers based on number of connected users
- Automated upgrades across Minecraft versions
- Automated mod/plugin updates
- Sharing of worlds across servers (could be an extension of the backup/restore mechanism)
- Hosting of client-side mods so that users can download the proper mods for a server without needing to track it down online
- MinecraftNetwork should validate that deployed servers in the network are compatible, and expose compatibility issues in the status
Super Stretch Goals That Might Just Be Impossible
- Scaling beyond 1 with a shared world
- Sharded servers
- Rolling updates (0 downtime)
- Control the deployed infrastructure from inside minecraft (ie kubecraft)
Edit: Move server network compatibility check to stretch goals
Thanks for writing this up! Here's my initial/random thoughts reading through this:
In "Minecraft" block
Add recovery mechanisms
can you expand on any initial ideas?
In "MinecraftNetwork",
Should deploy a default, minimal lobby server (possibly with version/mod compatibility plugins)
this sounds super awesome, but am wondering if that should even be another CRD itself or perhaps its a specific use of the "Minecraft" CRD. On the one hand it logically belongs with the bungee configuration since a lobby is required, but all the mod/plugin you mentioned would be an existing concern a "Minecraft" resource.
Also in "MinecraftNetwork"
Should validate that deployed servers in the network are compatible, and expose compatibility issues in the status
That seems like a stretch goal :) , but very cool
In "Stretch Goals"
Hosting of client-side mods so that users can download the proper mods for a server without needing to track it down online
I'd like to selfishly rank that one even higher; however, this might be a broader concern than the CRDs. It also would require researching leveraging of Twitch/Curse client's ability to load modpacks into the client.
Add recovery mechanisms
can you expand on any initial ideas?
I don't really have a concrete idea for this yet, I know you have a sidecar container for doing regular backups. A few other operators have XBackup/XRestore CRDs, which is probably the best way to do it for now. A MinecraftBackup would reference a specific Minecraft and create a backup, and a MinecraftRestore would reference a specific Minecraft and a specific MinecraftBackup. We could automatically create the MinecraftBackup resources when your sidecar creates a new backup (it would probably take the backup and put it in an entirely separate volume). The MinecraftRestore resource would spin down the server, copy the backup back into the real volume, bring the server back up and then probably delete itself on success.
Should deploy a default, minimal lobby server (possibly with version/mod compatibility plugins)
this sounds super awesome, but am wondering if that should even be another CRD itself or perhaps its a specific use of the "Minecraft" CRD. On the one hand it logically belongs with the bungee configuration since a lobby is required, but all the mod/plugin you mentioned would be an existing concern a "Minecraft" resource.
I would probably make it create a Minecraft CR, but it would be a predefined configuration that we know works well.
Should validate that deployed servers in the network are compatible, and expose compatibility issues in the status
That seems like a stretch goal :) , but very cool
Yeah good call
In "Stretch Goals"
Hosting of client-side mods so that users can download the proper mods for a server without needing to track it down online
I'd like to selfishly rank that one even higher; however, this might be a broader concern than the CRDs. It also would require researching leveraging of Twitch/Curse client's ability to load modpacks into the client.
Ah, I use multi-mc which would work quite well if we just hosted an archive, not sure about twitch/curse (we could also link/redirect to the modpage instead of pulling and hosting it)