ryzom-pipeline
commented
6 years ago Closed ryzom-pipeline closed 1 year ago
ryzom-pipeline
commented
6 years ago 
oxr463
commented
4 years ago @kaetemi why was this closed?
oxr463
commented
4 years ago Here is the source: https://gitlab.com/hexgearinc/ryzomcore-docker
kaetemi
commented
4 years ago It's not a priority. We already have an automated production deployment system (patchman_service) that's specialized for the requirements of the Ryzom services. I can't keep hundreds of idle tickets open ad eternum.
I fail to see how Docker provides any improvement for a game server, at this moment.
Keep in mind, the services make use of shared memory (mirror_service). Please describe the usage scenario for a Docker setup in detail.
kaetemi
commented
4 years ago Here's the reality. All the functional leveldesign and content tools are still Windows-only. If you're a leveldesigner, then the fastest workflow on a modern PC is to run a shard locally on your Windows environment, with direct access to your leveldesign working files, so you can reload at runtime. In practice, you just run a batch file that starts a bunch of executables.
You get nice windows for each services with big pushbuttons for reloading your leveldesign content, or whatever you like. Docker, especially on Windows, does not simplify any of this workflow.
kaetemi
commented
4 years ago Also. If you do build a Docker-based solution for development and production deployment... You need to include documentation on how to use it, otherwise it'll just end up another pile of orphaned code in the repository.
oxr463
commented
4 years ago That is a lot of feedback, and some of it seems out-of-scope for this issue; but I appreciate you taking the time to share your thoughts with me.
The biggest advantage that I see for using Docker, is it greatly simplifies the development workflow since the whole system can be spun up with a single command. This allows for a lower barrier of entry for new contributors.
If you decide not to use it then that is your decision, but closing the ticket without an explanation was confusing to me as a potential contributor; especially since I have been tracking the ticket for a few years now, (first on bitbucket, and now on GitHub).
Thanks again for your time.
kaetemi
commented
4 years ago I closed a whole batch of tickets that seemed idle and low priority.
kaetemi
commented
4 years ago As for being "out-of-scope". You have to take into account the reality of actually building a game. Ideals are nice, but secondary. At this point in time I am more concerned with getting the existing toolchains fully and thoroughly documented, it seems to be a more crucial effort.
I have yet to see a proposal for a Docker solution for Ryzom Core that can actually "spin up the whole system with a single command," and which can effectively be used to contribute across projects.
You'll have to walk me through the workflow of such a solution. :)
Looking at the requirements from a development perspective:
So, a Docker workflow is more than just adding a Dockerfile. You need to see where it fits in the entire workflow of who you're expecting to use it.
kaetemi
commented
4 years ago What I'm guessing you want is a Docker image that sets up
and uses the leveldesign assets from a local folder, so you can do leveldesign, correct?
oxr463
commented
4 years ago
- If you want to develop on the server code you'll have to run the services in a way you can attach a debugger.
Can you provide me a link to the documentation for this?
For QA, you can connect to a staging or daily server that's hooked to the existing toolchain. Deploying a daily server can already be automated right now.
For client development, you can do the same.
How can this be done as well?
From what it sounds like to me, you seem to be approaching this from the angle of an internal employee at a company, (I'm assuming you work for the company behind Ryzom?).
This isn't a bad thing, but most contributors are not in such a position. Using in-house workflows comprised of proprietary tooling and operating system alienates many potential contributors, since we don't know or use such technologies.
For example, I am not sure if this is still true, but the plugin used for some of the 3D conversions only worked with a version of 3DS Max that is no longer available for purchase. So unless someone already had that specific version, they could not compile the assets for the game.
What I'm guessing you want is a Docker image that sets up
- Shard that allows to bypass login
- Ryzom admin web tool to control the shard
and uses the leveldesign assets from a local folder, so you can do leveldesign, correct?
Basically, the original idea I had was to find a way to run a shard locally on my machine.
Docker is a common tool, but it doesn't have to be that. We could use Vagrant, or simply provide a virtual machine image with everything needed to have an instance up and running.
oxr463
commented
4 years ago This website mentioned an "Open Shard" instance that could be connected to, http://ryzomcore.com. Something like that could also work.
See also: https://ryzomcore.atlassian.net/wiki/spaces/RC/pages/884850/Open+Shard
kaetemi
commented
1 year ago We have a quick start package now that gives you the complete development workflow out of the box. A bit more fully featured. :)
https://wiki.ryzom.dev/development/quickstart_windows
Demo shard for Ryzom Core 4 is also up and will remain network compatible with core4 branch to facilitate client-only development.
Original report by Erwan GEORGET (Bitbucket: Dremor56, ).
Hello,
I work with the Khaganat team, and we recently started to look into Dockerize the server component. As our projects uses the same code base, we could work together to make it happen.
This would benefit both project greatly, as it would make it easier to deploy, maintain, and update the server, to use technologies like load-balancing, and workflows like continuous-delivery.
Regards,
Erwan "Dremor" GEORGET, system administrator for the Khaganat project.