(POOLER-109) Allow API to run independently#281
Merged
Conversation
Contributor
|
Is this up on our test instance of marathon? |
Contributor
Author
|
Yes, for vmpooler-provisioner-dev-2. If you look at cinext-test you will see a application folder containing the components for vmpooler running independently. |
This commit updates vmpooler to allow the API component and dashboard to run separately from pool_manager. Without this change vmpooler does not offer a mechanism to run only the API, or pool_manager components. Two instances of hardcoded puma environment settings are removed. This is still set in the init script explicitly as well as via an environment variable in the dockerfile. To extend the mechanism of running the API or pool_manager components to instances running in docker an entrypoint is added in the dockerfile. The entrypoint allows a user to specify whether to run the API or pool_manager components when running the application. The default behavior is preserved where both components are run. To support these changes vmpooler.rb is updated to allow more of the configuration to be specified via individual environment variables. It was already possible to specify the entire config block as an environment variable, but this is more difficult to manage and less of a standard implementation than specifying individual parameters. Where specified environment variable options will override a value configured via the configuration file or environment. The running pool configuration when starting pool_manager is loaded to redis at pool_manager start time. This allows the API to load the running pool configuration from redis and be able to run without requiring the pool configuration. Lastly, the dockerfile leveraging entrypoint will no longer start vmpooler with the init script or write logs to a file. Instead, LOGFILE is set to /dev/stdout and the vmpooler application is started directly. This behavior is preferred because the log file writes to disk are an unnecessary overhead. Without this change the docker installation will attempt to daemonize the vmpooler application and always requires puma.
f93758e to
3471851
Compare
Contributor
Author
|
@logicminds cc in case you have any opinions about the changes I'm making to vmpooler.gemspec. |
This commit updates gemspec and Gemfile in preparation of a vmpooler release. To support this change the vmpooler executable is placed into a bin directory for inclusion in the gem. The license in gemspec is updated to Apache 2.0 to reflect the vmpooler project license.
junebug-spencer
approved these changes
Jul 16, 2018
mchllweeks
approved these changes
Jul 16, 2018
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit updates vmpooler to allow the API component and dashboard to
run separately from pool_manager. Without this change vmpooler does not
offer a mechanism to run only the API, or pool_manager components.
Two instances of hardcoded puma environment settings are removed. This
is still set in the init script explicitly as well as via an environment
variable in the dockerfile.
To extend the mechanism of running the API or pool_manager components to
instances running in docker an entrypoint is added in the dockerfile.
The entrypoint allows a user to specify whether to run the API or
pool_manager components when running the application. The default
behavior is preserved where both components are run.
To support these changes vmpooler.rb is updated to allow more of the
configuration to be specified via individual environment variables. It
was already possible to specify the entire config block as an
environment variable, but this is more difficult to manage and less of a
standard implementation than specifying individual parameters. Where
specified environment variable options will override a value configured
via the configuration file or environment.
The running pool configuration when starting pool_manager is loaded to
redis at pool_manager start time. This allows the API to load the
running pool configuration from redis and be able to run without
requiring the pool configuration.
Lastly, the dockerfile leveraging entrypoint will no longer start
vmpooler with the init script or write logs to a file. Instead, LOGFILE
is set to /dev/stdout and the vmpooler application is started directly.
This behavior is preferred because the log file writes to disk are an
unnecessary overhead. Without this change the docker installation will
attempt to daemonize the vmpooler application and always requires puma.