# The typical path where we expect our Ruby wrappers to be deployed god.ruby.wrappers: /home/webservices/.rvm/wrappers/ruby-2.2.2@god p4webapi.ruby.gemset: /home/webservices/.rvm/gems/ruby-2.2.2@p4webapi p4webapi.ruby.wrappers: /home/webservices/.rvm/wrappers/ruby-2.2.2@p4webapi p4_phoenix_services.ruby.wrappers: /home/webservices/.rvm/wrappers/ruby-2.2.2@p4_phoenix_services p4_project_services.ruby.wrappers: /home/webservices/.rvm/wrappers/ruby-2.2.2@p4_project_services # The directory we write out security tokens into. web-services.token_path: /var/lib/perforce/web-services/tokens web-services.p4_project_services.bind: tcp://127.0.0.1:5001/ # TODO Reference the DB user and password defined in another pillar. # # This is an open issue at the moment, and unclear what the "right way" is. web-services.p4_project_services.db_url: postgres://perforce:h3lix4fun@localhost/p4_project_services web-services.p4_project_services.thread_min: 1 web-services.p4_project_services.thread_max: 32 web-services.p4_project_services.worker_processes: 2 web-services.p4_project_services.url: http://127.0.0.1/p4_project_services/v1 web-services.p4_phoenix_services.bind: tcp://127.0.0.1:5002/ # TODO Reference the DB user and password defined in another pillar. web-services.p4_phoenix_services.db_url: postgres://perforce:h3lix4fun@localhost/p4_phoenix_services web-services.p4_phoenix_services.thread_min: 1 web-services.p4_phoenix_services.thread_max: 32 web-services.p4_phoenix_services.worker_processes: 2 # This is for client workspaces used to submit files temporarily web-services.p4_web_api.workspace_dir: /tmp/web-services # The listen config for the p4_web_api unicorn server web-services.p4_web_api.listen: 5000 web-services.p4_web_api.url: http://127.0.0.1/p4_web_api/v1 # Number of unicorn processes for the P4 Web API. web-services.p4_web_api.worker_processes: 6 web-services.phoenix_updater.url: http://127.0.0.1/p4_phoenix_services/v1/updater
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#7 | 13972 | tjuricek |
Removing old microservice implementations. The system is now mostly a monolith. Eventually there will be a websocket service. |
||
#6 | 13675 | tjuricek |
Add notification_services initialization Removing the 'online setup' mode in lieu of doing things during the salt process. Mostly this removes the trigger setup from the main web application. |
||
#5 | 13535 | tjuricek |
Add notification_services to deployment, and reconfigure build step to exec bash. The execution bit doesn't seem to stay set on config/bash.sh The notification_services service doesn't have advanced tests just yet. |
||
#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 | 13517 | tjuricek |
Revised Salt hierarchy to allow for CD clustering. Now, there are two main salt environments: 'build' and 'eval'. The 'eval' environment can be configured for testing or development by setting the Grain 'dev_pillar: True' or 'test_pillar: True'. The test modes may need a bit more effort to figure out exactly where I'll put the .deb files. The dev box passes p4_web_api tests. |