# Initializes p4_project_services include: - perforce.web-services.p4_project_services.deps - perforce.web-services.p4_project_services.db {{ pillar['p4_project_services.dir'] }}/config.ru: file.managed: - source: salt://perforce/web-services/p4_project_services/config.ru - template: jinja require: - sls: perforce.web-services.p4_project_services.deps {{ pillar['p4_project_services.dir'] }}/config: file.directory: - makedirs: True {{ pillar['p4_project_services.dir'] }}/config/puma.rb: file.managed: - source: salt://perforce/web-services/p4_project_services/puma.rb - template: jinja require: - file: {{ pillar['p4_project_services.dir'] }}/config
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#5 | 13972 | tjuricek |
Removing old microservice implementations. The system is now mostly a monolith. Eventually there will be a websocket service. |
||
#4 | 13530 | tjuricek |
Add p4_phoenix_services package and Salt configuration for deployment. This uncovered a couple of issues from the C++ API during it's conversion to C++03. So, in a nutshell, most operations, except for notifications, appear to be working (well, using Vagrant machines). |
||
#3 | 13528 | tjuricek |
Moved rack and app server configuration to be managed via Salt. Also, only using a single value "url" to configure how the p4_project_services instance references the p4_web_api. And, removing the Docker setup, since that won't work for a production system. |
||
#2 | 13525 | tjuricek |
Setup God to manage both the p4 web api and p4 project services processes. Apparently, there can only be one true god per machine. |
||
#1 | 13515 | tjuricek |
Initial configuration for the p4_project_services. The tests haven't been run yet, so it's likely missing some more configuration. Using vagrant to even manage these environments may not be our realistic CD premise. I may end up moving some more responsibility into the Salt layer, which would make vSphere automation easier. |