airtonix

@itsatrap Migrating a live production database with git. I find this idea both intriguing and hilarious in your misunderstanding of the problems faced when running production applications. But if you mean to assume that any extensions/addons I would write for exile would actually go in the same directory... wow. I have no words. Anyway for lulz, I fired up my docker setup of exile server, using the incredibly simple to use tool "docker-compose": version: '2' services: db: image: mariadb env_file: - ./env/exile.mysql.env web: image: python:2.7 env_file: - ./env/exile.mysql.env - ./env/exile.web.env volumes: - './web:/app' server: image: houki/arma3 env_file: - ./env/exile.mysql.env - ./env/exile.server.env volumes: - './game/arma3:/arma3' command: - './arma3server' - '-port=2302' - '-servermods=@exileserver,@exile,@extdb2' So first off I just imported your mysql file manually, then I shelled into the web container and ran it's inspectdb command to generate all the required django models: docker exec -it exile_web_1 ./manage.py inspectdb > ./web/exile/models.py This generated a nice file with all the correct models factored apart from reverse naming conflicts with : 'Account.clan' <> 'Clan.leader_uid' 'Territory.stolen_by' <> 'Account.uid' These just require me to annotate those fields with an appropriate reverse name, so : class Account(models.Model): ... clan = models.ForeignKey('Clan', primary_key=true, models.DO_NOTHING, related_name='members', blank=true, null=true) ... class Territory(models.Model): ... stolen_by = models.ForeignKey('Account', primary_key=true, models.DO_NOTHING, related_name='stolen_flags', blank=true, null=true) ... It's worth noting that initially these models are marked as unmanaged by Django, so we'll just delete those declarations. After that, we add the new exile module to installed_apps and run the command to generate a migration (because the models already exist in the database). Because this is the first migration, it'll only create necessary database tables and/or columns. docker exec -it exile_web_1 ./manage.py makeschemamigrations exile This creates a migration file in ./web/exile/migrations/* which can be part of version control. Then run the migration docker exec -it exile_web_1 ./manage.py migrate exile So from now on, any changes to the schema should be done via the web/exile/models.py. So @Eichi, on reflection, having declared that you won't be changing the database is good, because it means any future changes to the databse can be safely done through migrations.

It's a shame you feel that way, because upgrading an existing Exile database is a nightmare. And I'm not sure how you expect people to make extensions for Exile without established points of interface. Actually fortune 500 companies have the worst coding standards. And no, php is just a language, mysql doesn't provide a robust migration framework. I'm interested to hear your detailed solutions.

--- forum needs a delete button.

@Eichi Not really, but knowing the public points of the api and the network communication schema will establish a standard. - I am mildly curious about providing the django solution; I know from experience that updating a production database is far easier and reliable when you have a migration framework managing it for you. - once the django thing is done, anyone can use the django ecosystem to add their own external features (notifications, offline map notes, forums, etc).

@Flosstradamus We'll actually it is. OP pointed out a logic flaw he was experiencing. You countered that it wasn't anything to do with exile. Second poster comes in with proof that proves you wrong, and you continue to claim it has nothing to do with exile... Yet you think someone else is being a dick? Right, what algebra/philosophy class did I miss that helps me understand your thoughts?

I await a fully documented api, providing us with the means to properly integrate with @exile as a core. Also, suggest you start providing migration strategy for the sql. Using Django from the start to provide a simple admin web interface would have also given you a free database lifecycle management system.

Or don't allow the flag to move to a position where it leaves current items outside its radius.

@jessytheripper I also have been working on an approach to spinning up exile with docker. Cloned your repo and I've got a few suggestions: Split your images into three: busybox data image mariadb image arma3 game server image make pre-exec.d and post-exec.d volumes. move installing the tanoa map into pre-exec.d/maps.tanona.upgrade.sh use a feature flag assertion check for each common set of operations. As a server admin, I may only want to upgrade a specific thing. Once you have things a little more generic and a clear separation of concerns, you can spin up multiple instances more reliably. This project really helps delegating management of systems to less technically apt server admins: - http://rancher.com/ sudo docker run -d --restart=always -p 8080:8080 rancher/server

@ole So I stepped through the guide again, and it works now. only thing I've done differently is packing the mission up into a pbo instead of using it like a folder. The mission as a folder worked without using admintoolkit... anyway, here's the steps for others: https://gist.github.com/airtonix/06f8d2a8ce76b41074a7dac7db51ab9e

@ole Nothing except messages that admintoolkit has loaded. I'll step through the guide again and document: a) exactly what I did, b) any confusions I'm having interpreting your guide.

@ole Client crashes memory exception Situation is as follows: @AdminToolkit loaded as client mod (along with @Exile) Server configured by following your instructions on github: Removing all these modifications, allows my client to connect without crashing.

You probably want to start here: https://github.com/search?q=extDB2 ArmaLife project might be a good repo to source it from.

Please, in your server releases, make use of a migration tool. https://www.npmjs.com/package/migrit https://www.npmjs.com/package/db-migrate Hardcoding file names to run against mysql is very fragile. $ migrate ./migrations up much better.

I've been thinking about this approach Eichi and Crew took and with my 10+ years experience in web development and 4 years experience in the startup circles, I came to the following conclusions: Ruling out email notifications was smart. Even with Job queues and horizontally scaled frontend nodes or a service like mandril, email is by definition not real time. Should have written it as a web app first, utilising websockets and vuejs. outcome: works on all platforms. Start with notifications only when the app is open. Gauge market traction from there. Write a small nodejs websocket server app that server owners can configure and deploy For 2nd stage notifications, use Slacks incoming webhook feature. Server owners create their own Slack presence, players can then get private notifications. Slack is very extensible. Case in point for a web app. True, but this was the reality for Android for a long time. Websites made for iOS are not going to create an enjoyable experience for non ios users. second case in point for a web app Probably because Eichi and team decided to do more before qualifying demand for specific details. When the Exile sourcecode isn't open, the development process not transparently available, the conversations around rejecting pull requests.... etc; the rest of us are left with fear and doubt to fill in the gaps. It was a wise idea to avoid integrating twilio... It gets very expensive. A suggestion I'd make with regards to the app integration is this, take a page out of Elom Musks book: > You may have the ability to engineer a solution to a problem, but doing so will spread you thin. So, going forward: modify the code paths in the game server that makes calls to your centralised notification service provide configuration points that allow us to target where these webhooks go (ie my own nodejs web app) Do that first, publish the specs on the communication api, then let the community come up with some tools to provide our own solutions.

To be brutally honest, Exile devs have over-engingeered the app. A simple nodejs express powered server running on the same server as the exile server would have been enough. Going full push notifications forced the exile developers to choose between amazon SQS, Parse (docker hosted or otherwise) or some other SaaS offering. This is the part where costs are un-avoidable. However by simply managing expectations down a notch, and utilising a simple ExpressJs websocket server running on the same machine as the game server, this cost could be eliminated. Taking on centralised infrastructure when you have no proven market demand or even traction is one of the things I've learnt to avoid in the startup world. The following parts could have been used to decentralise the notifications: - https://bitbucket.org/micovery/sock-rpc - http://expressjs.com/ - https://www.npmjs.com/package/express-ws