33c96d0066
Socket read operations can be blocking and may not timeout as
expected when thinking of timeouts at the beginning of a
socket request. This can occur when streaming file contents
down to the agent and there is a hard connectivity break.
In other words, we could be in a situation like:
- read(fd, len) - Gets data
- Select returns context to the program, we do things with data.
** hard connectivity break for next 90 seconds**
- read(fd, len) - We drain the in-memory buffer side of the socket.
- Select returns context, we do things with our remaining data
** Server retransmits **
** Server times out due to no ack **
** Server closes socket and issues a FIN,RST packet to the client **
** Connectivity restored, Client never got FIN,RST **
** Client socket still waiting for more data **
- read(fd, len) - No data returned
- Select returns, yet we have no data to act on as the buffer is
empty OR the buffered data doesn't meet our requried read len value.
tl;dr noop
- read(fd, len) <-- We continue to try and read until the socket is
recognized as dead, which could be a long time.
NOTE: The above read()s are python's read() on an contents being
streamed. Lower level reads exist, but brains will hurt
if we try to cover the dynamics at that level.
As such, we need to keep an eye on when the last time we
received a packet, and treat that as if we have timed out
or not. Requests periodically yeilds back even when no data
has been received, in order to allow the caller to wall
clock the progress/status and take appropriate action.
When we exceed the timeout time value with our wall clock,
we will fail the download.
Change-Id: I7214fc9dbd903789c9e39ee809f05454aeb5a240
(cherry picked from commit
|
||
|---|---|---|
| doc/source | ||
| imagebuild | ||
| ironic_python_agent | ||
| releasenotes | ||
| tools | ||
| zuul.d | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .travis.yml | ||
| CONTRIBUTING.rst | ||
| LICENSE | ||
| README.rst | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| plugin-requirements.txt | ||
| proxy.sh | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Ironic Python Agent
Team and repository tags
Overview
An agent for controlling and deploying Ironic controlled baremetal nodes.
The ironic-python-agent works with the agent driver in Ironic to provision the node. Starting with ironic-python-agent running on a ramdisk on the unprovisioned node, Ironic makes API calls to ironic-python-agent to provision the machine. This allows for greater control and flexibility of the entire deployment process.
The ironic-python-agent may also be used with the original Ironic pxe drivers as of the Kilo OpenStack release.
Building the IPA deployment ramdisk
For more information see the Image Builder section of the Ironic Python Agent developer guide.
Using IPA with devstack
This is covered in the Deploying Ironic with DevStack section of the Ironic dev-quickstart guide.
Project Resources
Project status, features, and bugs are tracked on StoryBoard:
Developer documentation can be found here:
Release notes for the project are available at:
https://docs.openstack.org/releasenotes/ironic-python-agent/
Source code repository for the project is located at:
- IRC channel:
-
#openstack-ironic
To contribute, start here: Openstack: How to contribute.