…iguration with built-in support for APC, memcache, mongo and redis. Change-Id: Icf1bdb17f4b1865afa350704937874f5787b3457
…iguration with built-in support for APC, memcache, mongo and redis. Change-Id: I2d2bc61bc289a0bc7a92eb1c8e5c3f41375437f1
…t deployment config files"
Fixes problem where gem complains that the pg_config isn't available. Change-Id: I1463e2139c4c79fdab8dcc4037bc1ae9386f204e
Fix for issue cf-135. Usually the pakcage command does the right thing but that would only work if the same version of java is installed, if openjdk or some other flavour is installed the package command fails misreably in this case because it cant find the right repo. Change-Id: I1aef325e557d338141e68dbd91a070b438f62563
- Adds logging/error reporting if: -- Creating the instance dir fails -- Unzipping the droplet fails - Sends notification to the HM that the app has crashed so that it will ultimately end up marked as flapping. Test plan: - BVTs pass locally - BVTs pass on my deployment - Added unit tests exercising failures to stage the instance dir - Verified that HM was notified via: -- Deployed the env app locally -- Corrupted the droplet "echo foo > /var/vcap/shared/droplets/XXX" -- Stopped/Started the app -- Verified that the HM received the crash notification -- Verified that the app was placed into the flapping state Change-Id: Iba7cb521fcf9864271bd2b0844e2f1eee5774fde
bin/vcap - fix a bug where the specified config file was not being used to lookup properties. bin/vcap_dev_setup - check for git clone failures job_manager.rb - remove postgresql as a services patch 2 - fix $configdir => $config_dir Change-Id: Ie0214ce340f62f585f6233a7c7de1e78cc6e1ad8
…yment config files The deployment config file doesnt need to be an .erb file anymore. Removed some old code that was using it as an erb file. Also remove the old config samples in deployments/multihost. patch 3 Added: sample config files for multihost redis patch 4 Remove more old/outdated sample files patch 5 Hit myself on the head.(Added white space remover to vi) Change-Id: I402e5de08eb9a1fa26c6489ca138d5da7229cf14
This moves the call to close_fds up to immediately before executing the shell/su that ultimately spawns the app. Test plan: - BVTs pass both locally and on my deployment - Verified that DEA children do not have a connection to NATS using lsof Change-Id: I27b6f86c06bf3476ea527cd8fcf41946c9efcb3e
…ap_dev_setup_url) Change This review has changes related to the following 3 things. 1. Move all the default config (that was embeded in vcap_dev/vcap_dev_setup/job_manager) into chef cookbooks. 2. Add postgres CCDB. 3. Multi host setup for services and dea. This meant separating service gateway from service nodes. To this effect we added a service gateway role. Overall a lot of files have changed, most of those changes are related to moving all the default config values from the various wrapper scripts to the cookbooks, especially the new cookbook called deployment which is the holding place for all the deployment related config options. * dev_setup/bin/vcap: Added vcap to dev_setup/bin instead of just changing bin/vcap. The reason for this is that opensource CF code will not be in sync with the private repo and internal testing of CF dev_setup scrips would not work if it relied on the version of vcap in the opensource repo i.e. bin/vcap. So now we just package vcap with dev_setup. * vcap_dev * Since all defaults are now maintained in chef scripts. The chef "deployment" * role/recipe creates a deployment info file that is consumed by this vcap_dev * script. * The vcap_dev_setup file now saves the list of components that were installed for a deployment. This script only starts the components included in that list. * Uses the vcap binary from dev_setup/bin * vcap_dev_setup Moved a bunch of directory creating code to the deployment cookbook * Added a CCDB role/recipe. * Creates and Configures the CC postgres database. * Added deployment cookbook * Moves all the comon directory creation code here. Note, we should go back and see if we really do need all these various directories and probably come up with a well designed directory layout. Testing: * Ran BVTS. Lift BVT failure needs investigating (I will fix/get to the bottom of it before i submit this change) * Tested the following multi host setup. 1. Ran mysql database with mysql node on 2 VMs. On a 3rd VM ran everything else. Verified that BVTs passed. 2. Ran dea on 2 different VMs. Ran everything else on a 3rd VM. Verified that BVTs passed. Note: I have only tested the multihost setup with mysql. I will test mongodb and redis before submitting this change, I expect those to run without any glitches. Change-Id: I6a084be09a81bf920eebc62be8d7aa6625cc17e9
…ks/runtimes around that are no longer in the DB - Added started apps and instances - Aggregated queries to reduce number of requests"
For applying this fix, you can use MySQL (/w em_mysql2 adapter) as cloud controller database by configuring cloud_controller.yml as follows: development: database: cloudcontroller host: localhost port: 3306 username: root password: password adapter: em_mysql2 encoding: utf8 timeout: 2000 Change-Id: Ie881f617f77d1d4aacc0772b1594547b9beb1af5