|
Post by Telesphoreo on Jun 8, 2020 23:35:20 GMT
I don't understand what's so horrible about setting up Ansible templates for our plugins and server and using docker-compose to execute a Dockerfile which sets up a Docker container and runs Ansible to generate the server to our exact specification. It does exactly what we need, enables an automated process, and can be combined with a TravisCI integration/build cycle for us to be able to build updates and deploy them to either a QA or prod server. Think about it, if we just put in the effort to use these tools, all we have to do is basically press a button to kick off a process which automatically sets up the entire server, builds the jars, and deploys it. A versioning system would do great for us, we can use Git tags to keep track of exactly what version of what plugins we want to be rolled out through our deployment system. We'd be able to make plugin changes, use a QA tag, then deploy changes to QA automatically and we'd be able to test everything there instead of using our production server as a testing server. We have system administrators here, we have developers here (and 85% of this has little to do with actual development work), this can be set up for us. You're right, but if Seth doesn't want to do this, all I can offer is a Bash script running on a cron job to keep stuff up to date. Object. What I have against using small forks maintained by one person is that if that person decides to stop maintaining it, you suddenly have to switch everything back. On top of that, since the fork has fewer developers than the upstream repository (Paper), it will release less often, so you are always behind on patches that are made upstream. Good. If something is going to be kept up to date it ought to be Tuinity. Changes from Paper are merged into Tuinity when they're stable. It's good that it's behind, because if there's a faulty version of Paper, then it doesn't get merged into Tuinity. And doing less updates with more changes is better than constant restarts for every single build. It's not like these are cars and everything is slightly different. If Tuinity stops being maintained, then we can switch back to Paper. It's not like once the server runs Tuinity once, you can never ever use Paper again. And can't the same argument be made for Paper? What if they stop supporting Paper. You can even jump from Tuinity to Spigot, you just lose the performance improvements, but the server isn't going to break. reminder to all that the version of paper we have on the server is more than 100 versions behind or something like that, Seth said he gonna update it when he comes back or mabye when 1.16 releases, but I thought you all should know that Updating Paper itself would absolutely help, but why not switch to Tuinity if it's gonna happen anyways. After using AMP for the SMP server, I honestly understand why Seth never updates anything. The transfer speed is like 20 kb/s and it takes 30 minutes to upload a new paper update, and even a few minutes for some basic plugins. This would obviously be solved if we used a more competent panel software like Pterodactyl, or just wget the files to the server instead of uploading them from your computer to AMP (or just use a deployment system). Fundamentally, it's a Minecraft server. If TPS dramatically drops just because somebody joins (which is the reason why this version of the server software exists in the first place I believe), that's something that will occur regardless of what kind of server is being ran. It does show you how awful Minecraft has gotten over the years, though, when people are scrambling to fork the fork of the fork of Bukkit which in itself is a modification to make these optimizations. Tuinity is optimized for servers with high playercounts. SMP isn't bustling, but it certainly did help with the TPS drop when a player joins. SMP doesn't have any schedules to run, so there aren't lag spikes every 5 or 10 minutes.
|
|
|
Post by Polaris Seltzeris on Jun 8, 2020 23:37:49 GMT
I don't understand what's so horrible about setting up Ansible templates for our plugins and server and using docker-compose to execute a Dockerfile which sets up a Docker container and runs Ansible to generate the server to our exact specification. It does exactly what we need, enables an automated process, and can be combined with a TravisCI integration/build cycle for us to be able to build updates and deploy them to either a QA or prod server. Think about it, if we just put in the effort to use these tools, all we have to do is basically press a button to kick off a process which automatically sets up the entire server, builds the jars, and deploys it. A versioning system would do great for us, we can use Git tags to keep track of exactly what version of what plugins we want to be rolled out through our deployment system. We'd be able to make plugin changes, use a QA tag, then deploy changes to QA automatically and we'd be able to test everything there instead of using our production server as a testing server. We have system administrators here, we have developers here (and 85% of this has little to do with actual development work), this can be set up for us. You're right, but if Seth doesn't want to do this, all I can offer is a Bash script running on a cron job to keep stuff up to date. It doesn't just have to be Seth setting it all up though, there are people here that would volunteer to set up such a system.
|
|
|
Post by Telesphoreo on Jun 9, 2020 0:05:32 GMT
You're right, but if Seth doesn't want to do this, all I can offer is a Bash script running on a cron job to keep stuff up to date. It doesn't just have to be Seth setting it all up though, there are people here that would volunteer to set up such a system. You're right. Nothing I can do about that. You can bring a horse to water but you can't force it to drink it.
|
|
StevenNL2000
Forum Admin
Posts: 6,415
| Likes: 6,936
IGN: StevenNL2000
Timezone: UTC+01:00
Member is Staff. Need immediate assistance? Send a PM
|
Post by StevenNL2000 on Jun 9, 2020 7:58:40 GMT
Changes from Paper are merged into Tuinity when they're stable. It's good that it's behind, because if there's a faulty version of Paper, then it doesn't get merged into Tuinity. And doing less updates with more changes is better than constant restarts for every single build. Which is why you don't update the second a new version comes out. You're essentially saying that a fork is better just because it pulls in upstream less often. And can't the same argument be made for Paper? What if they stop supporting Paper. I specifically talk about forks maintained by one person because that's where the highest danger is. Even a second person already decreases that chance tremendously. It's the difference between "I am leaving this project" and "I declare this project dead".
|
|
|
Post by Polaris Seltzeris on Jun 9, 2020 8:04:48 GMT
Changes from Paper are merged into Tuinity when they're stable. It's good that it's behind, because if there's a faulty version of Paper, then it doesn't get merged into Tuinity. And doing less updates with more changes is better than constant restarts for every single build. Which is why you don't update the second a new version comes out. You're essentially saying that a fork is better just because it pulls in upstream less often. And can't the same argument be made for Paper? What if they stop supporting Paper. I specifically talk about forks maintained by one person because that's where the highest danger is. Even a second person already decreases that chance tremendously. It's the difference between "I am leaving this project" and "I declare this project dead". I feel like your criticism is all technically correct, but no longer viable anymore because of the crappy state of things in relation to Minecraft server development. Bukkit existed as a hack-free server modification with high quality/development standards, then it died, Spigot came along to modify it and blew away half of those hack-free standards and development standards, it became a rotting zombie of a dead server mod at that point and I'm sure that's one reason why servers are just less stable in general these days (and the Minecraft developers themselves not caring to optimize despite the growing scale of Minecraft, I mean the game has grown exponentially since 2010 but the networking architecture is still 2010, no scalability). Then you have more forks on top of that to make up for those optimizations, and it just gets out of hand. Basically, the situation in general is already out of hand, and there isn't a perfect option here when it comes to picking which modification of the modification is best for us. We could use Paper, we could use what's being suggested here, we could use Spigot, really the more you go downstream it does become a lot more complicated and risky but you also get the benefits of downstream optimizations. It's terrible but I think there is a valid choice here and because of that I don't think this suggestion is necessarily a bad idea at all.
|
|
|
Post by SupItsDillon on Jun 9, 2020 13:09:54 GMT
Changes from Paper are merged into Tuinity when they're stable. It's good that it's behind, because if there's a faulty version of Paper, then it doesn't get merged into Tuinity. And doing less updates with more changes is better than constant restarts for every single build. Which is why you don't update the second a new version comes out. You're essentially saying that a fork is better just because it pulls in upstream less often. And can't the same argument be made for Paper? What if they stop supporting Paper. I specifically talk about forks maintained by one person because that's where the highest danger is. Even a second person already decreases that chance tremendously. It's the difference between "I am leaving this project" and "I declare this project dead". If Tuinity does stop getting supported, there is always the option of going back to paper or spigot or whatever. It isn’t like it’s gonna kill the server, there’s always other options.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 20, 2020 15:17:22 GMT
I'm going to hold off on this for now. We've been having stable TPS and big uptimes (up to 8 hours) all the times I've checked.
|
|