webservices.groups: [ rvm, vagrant ] p4_web_api.dir: /home/vagrant/p4ws/p4_web_api/p4_web_api p4_web_api_client.dir: /home/vagrant/p4ws/p4_web_api/clients/ruby/p4_web_api_client p4_web_services_auth.dir: /home/vagrant/p4ws/p4_web_services_auth p4_project_services.dir: /home/vagrant/p4ws/p4_project_services/p4_project_services p4_project_services_data.dir: /home/vagrant/p4ws/p4_project_services/p4_project_services_data p4ruby.dir: /home/vagrant/p4ws/p4ruby local_root: /home/vagrant/p4ws deps.use_packages: False seed_data: True rvm.install_user: vagrant
# | 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 | 13707 | tjuricek |
Infrastructure for including a "project management" React application. This attempts to create a fairly simple installer that creates a 'static' folder based on ui/static that gets hosted by the nginx front end. Right now, it's the only app, so the default page is this application. It was called "pws2" during a prototyping phase. Another prototype, "pws" and the related "project" module, is removed since that was a Sinatra-based approach that will be much more difficult to integrate into anything else. I'm running into a couple of issues with notifications setup, it's still not 100%, so I'm disabling this for now from the default 'god' configuration. (The service isn't 100% functional yet, anyway.) |
||
#5 | 13635 | tjuricek |
Exploring modular web applications with Sinatra. If the app has fairly unique content per page, Sinatra works really well actually. (Mostly because it's a thin layer over Rack.) Sharing anything though, basically means implementing a module or base class and implementing it everywhere. An added benefit is that these applications could be used in Rails apps as well. I'd probably think hard about this, because Rails tends to be a resource hog. Here's an example config.ru I used for running against the dev system: require 'pms' app = Pms::App.new Pms::Login.settings.p4_web_api_url = http://172.16.100.20/p4_web_api/v1 ProjectApp.settings.phoenix_services_url = http://172.16.100.20/p4_phoenix_services/v1 app.settings.static = :true app.settings.public_folder = File.absolute_path('../../ui/pms', __FILE__) puts "public_folder is #{app.settings.public_folder}" run app |
||
#4 | 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. |
||
#3 | 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). |
||
#2 | 13520 | tjuricek |
Created a 'cluster' build procedure that creates an installer on build, and executes the install on a test instance. The main change is to package all gem dependencies via 'vendor/cache' (using the 'bundle package' command). Right now, there appears to be an issue with test data initialization, which may need a revised approach. |
||
#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. |
||
//guest/perforce_software/helix-web-services/main/salt/minion/dev/pillar/dev.sls | |||||
#2 | 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. |
||
#1 | 13512 | tjuricek |
Add 'test-ubuntu12' environment that sets up projects based on "production" packages. Packages are installed from source files that should have been created by the last 'build-ubuntu12' environment. Since the package building process "dirties" up the environment it's better to use a clean system to test package installation. |