b8035de65f
If a provider (or its configuration) is sufficiently broken that the provider manager is unable to start, then the launcher will go into a loop where it attempts to restart all providers in the system until it succeeds. During this time, no pool managers are running which mean all requests are ignored by this launcher. Nodepool continuously reloads its configuration file, and in case of an error, the expected behavior is to continue running and allow the user to correct the configuration and retry after a short delay. We also expect providers on a launcher to be independent of each other so that if ones fails, the others continue working. However since we neither exit, nor process node requests if a provider manager fails to start, an error with one provider can cause all providers to stop handling requests with very little feedback to the operator. To address this, if a provider manager fails to start, the launcher will now behave as if the provider were absent from the config file. It will still emit the error to the log, and it will continuously attempt to start the provider so that if the error condition abates, the provider will start. If there are no providers on-line for a label, then as long as any provider in the system is running, node requests will be handled and declined and possibly failed while the broken provider is offilne. If the system contains only a single provider and it is broken, then no requests will be handled (failed), which is the current behavior, and still likely to be the most desirable in that case. Change-Id: If652e8911993946cee67c4dba5e6f88e55ac7099 |
||
|---|---|---|
| contrib/statsd_exporter | ||
| doc | ||
| etc | ||
| nodepool | ||
| playbooks | ||
| releasenotes/notes | ||
| roles/nodepool-zuul-functional | ||
| tools | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| Dockerfile | ||
| LICENSE | ||
| README.rst | ||
| TESTING.rst | ||
| bindep.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Nodepool
Nodepool is a system for managing test node resources. It supports launching single-use test nodes from cloud providers as well as managing access to pre-defined pre-existing nodes. Nodepool is part of a suite of tools that form a comprehensive test system, including Zuul.
The latest documentation for Nodepool is published at: https://zuul-ci.org/docs/nodepool/
The latest documentation for Zuul is published at: https://zuul-ci.org/docs/zuul/
Getting Help
There are two Zuul-related mailing lists:
- zuul-announce
-
A low-traffic announcement-only list to which every Zuul operator or power-user should subscribe.
- zuul-discuss
-
General discussion about Zuul, including questions about how to use it, and future development.
You will also find Zuul developers in the #zuul channel on Freenode IRC.
Contributing
To browse the latest code, see: https://opendev.org/zuul/nodepool To clone the latest code, use git clone https://opendev.org/zuul/nodepool
Bugs are handled at: https://storyboard.openstack.org/#!/project/zuul/nodepool
Code reviews are handled by gerrit at https://review.opendev.org
After creating a Gerrit account, use git review to submit patches. Example:
# Do your commits
$ git review
# Enter your username if promptedJoin #zuul on Freenode to discuss development or usage.
License
Nodepool is free software, licensed under the Apache License, version 2.0.
Python Version Support
Nodepool requires Python 3. It does not support Python 2.