Skip to content

(POOLER-109) Allow API to run independently#281

Merged
mattkirby merged 5 commits into
puppetlabs:masterfrom
mattkirby:pooler_109
Jul 16, 2018
Merged

(POOLER-109) Allow API to run independently#281
mattkirby merged 5 commits into
puppetlabs:masterfrom
mattkirby:pooler_109

Conversation

@mattkirby

Copy link
Copy Markdown
Contributor

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.

@junebug-spencer

Copy link
Copy Markdown
Contributor

Is this up on our test instance of marathon?

@mattkirby

Copy link
Copy Markdown
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.
@mattkirby mattkirby force-pushed the pooler_109 branch 2 times, most recently from f93758e to 3471851 Compare July 13, 2018 16:40
@mattkirby

Copy link
Copy Markdown
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.
@mattkirby mattkirby merged commit 95d9c83 into puppetlabs:master Jul 16, 2018
@mattkirby mattkirby deleted the pooler_109 branch July 16, 2018 23:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants