search

fabianvf / game-server-operator

MIT License
18 stars 3 forks source link

Minecraft Operator 1.0 Roadmap #5

Open fabianvf opened 5 years ago

fabianvf commented 5 years ago

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
MinecraftNetwork
Packaging
Stretch Goals
Super Stretch Goals That Might Just Be Impossible

Edit: Move server network compatibility check to stretch goals

itzg commented 5 years ago

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.

fabianvf commented 5 years ago

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)