# TODO The threads and workers should really come out of app config threads 8,32 workers 2 bind ENV['BIND_ADDRESS'] || 'tcp://127.0.0.1:5001' stdout_redirect '/var/log/perforce/web-services/p4_project_services.stdout.log', '/var/log/perforce/web-services/p4_projet_services.stderr.log', true
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#8 | 13532 | tjuricek |
Qt SDK: Add constructor that uses an application's QSettings for caching Sessions for each URL Added a simple validateSession remote call to ping the services instance to see if the session is indeed usable. Also, removing puma configuraiton that is automatically generated in the (shared) development instance. |
||
#7 | 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). |
||
#6 | 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. |
||
#5 | 13527 | tjuricek |
Added a basic p4-project-services .deb package There is some kind of configuration issue with the production config that causes tests to fail. The service is running, however, so this is likely related to having a few things not managed via salt. |
||
#4 | 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. |
||
#3 | 13487 | tjuricek |
Pushing host, port, and URL configuration into docker-compose.yml consistently. All other configuration will be figured out by a separate system later. P4WEBAPI-51 |
||
#2 | 13478 | tjuricek |
Added Docker configuration for notification services, and phoenix services, also, opened up most ports to the host by default. The current configuration is now working first for a setup of "development mode" environments, anticipating that each service will use the private internal network for most services. That way, you can selectively run things, say, in your OS X environment, and other things in the docker cluster. It can make your debugging a little easier. When more automation is available, we'll find a way to describe how to handle this in different ways. |
||
#1 | 13477 | tjuricek |
More docker-compose configuration for projects in research for HSM. Added a geminabox host for the cluster, which allows for quick rebuilds. Each cluster will cache the gems it needs, and publish as well. We may want to put the overwrite commands for all publish steps by default. Note: referencing "external links" can only be done 'at runtime', so "bundle install" really needs to be run in the context of 'docker-compose up' not 'docker-compose build'. This was edited in all configured libraries so far. Finally, added the p4_project_services projects to configuration, which is running under it's own puma instance. The postgres instance is a little tricky to figure out the exact workflow. Right now I'm using the host rake db:migrate task and calling createdb manually, since we need to pass the password along. |