We need to specify doc requirements in doc/requirements.txt
to avoid problems with the pip resolver for the release team.
Removed specific doc requirements from test-requirements.txt
Change-Id: Ib2570e01bef426c0e5ecfd59249d08ea00749b28
Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Set openstackdocs_pdf_link to link to PDF file. Note that
the link to the published document only works on docs.openstack.org
where the PDF file is placed in the top-level html directory. The
site-preview places the PDF in a pdf directory.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: I20ea481c1dd9651258b8ae13da9b1e1ec710482b
Adds the ability to override default configuration file location
by exporting the ``VIRTUALBMC_CONFIG`` variable, pointing to the
desired config file, into ``vbmcd`` and ``vbmc`` processes
environment.
Change-Id: I89f7cab09f4c0b2c1d2517c4b6f607ed291f235c
This is a followup patch to [1] addressing minor
fixes and improvements in the documentation.
1. https://review.openstack.org/#/c/488874
Change-Id: I20f020feecf3e7d97ed6771d2061a12834ea5250
Original design of the VirtualBMC tool was that user manages
config files for individual VirtualBMC (via a cli tool), then
requests the tool to start the instances representing
individual VirtualBMC instances (via the cli tool). Then
the instances become independent processes. The only way
to know their whereabouts is through the pidfiles
they maintain.
There were certain practical inconveniences with the
original design, namely:
* Cumbersome to start/stop/monitor free-standing
vBMC instances processes
* No two-way communication between the parent process
and the VirtualBMC instances what makes child state check
or modification unnecessary difficult
This commit turns server part of the tool into a single
process spawning multiple children processes and herding
them via ZMQ client/server.
The parent process runs server part of the control
interface, maintains persistent VirtualBMC instances
configuration and ensures all its children are alive
and kicking. Each VirtualBMC instance is still a separate
parent fork.
If child dies, parent respawns it right away. If parent
is about to die, it tries its best to kill all the
prospective orphans.
This new implementation tries to stay compatible with
the original one in part of `vbmc` tool CLI interface
and behaviour. Whenever it can't connect to the `vbmcd`
it tries to fork and spawn the daemon behind the scenes.
While the threading design for this tool might look better,
the underlying pyghmi library is apparently rather
complicated to use its concurrency capabilities reliably.
The other minor consideration is that running multiple
processes leverages CPU-based concurrency.
Other changes:
* The `start` command now accepts more than one domains
to be started
Change-Id: Ie10f4598c7039a7afa9b45d01df3b3c3db252c1d
Story: 1751570
Task: 12057
This reverts commit 9f7bfb9f6b.
It seems that the SOL feature introduced by patch [1] led to
the VirtualBMC daemons leaking two file descriptors (ends of
UNIX pipe, perhaps) per each IPMI query it processes. Given the
default ulimit of 1024 open files per process, in circa 500 IPMI
queries vbmc renders itself not quite functional.
The quick research of the problem reveals that the leak comes
to life once the virEventRegisterDefaultImpl() call is made
which prepares libvirt for asynchronous operations over a dedicated
connection to libvirtd. Even though once SOL session is gone and
libvirt is cleaned up (well, dedicated connection is closed),
the libvirt connection, which is open every time when IPMI query
comes in, leaks 2 FDs per query.
This problem has been reported about some other libvirt application
in the past [2] so the problem might go away if we turn the IPMI
part of vbmc to the asynchronous operation mode as well.
Another observation is that libvirt API may not [3] offer a full
clean up upon exiting from the asynchronous operation mode.
To summarize: the real cause of this behaviour is not yet properly
understood.
1. https://review.openstack.org/#/c/482853/
2. https://www.redhat.com/archives/libvir-list/2013-September/msg00019.html
3. https://github.com/libvirt/libvirt/blob/master/src/util/virevent.c#L224
Change-Id: Id599f62e0eaf8c96e4552d2cd263f93155f8afa6
Story: 2001976
Task: 19585
This patch adds some methods to support Serial-over-LAN capability.
We'll be able to connect serial console of a domain with
"ipmitool sol activate" command.
SOL capability requires a persistent libvirt connection, so this
patchset adds libvirt_open.get_conn() method and use it.
Change-Id: I7f9dfbd2b3eb1320be755bade2f97b9f0621d409
This patch fixes the documentation title, the name of the project is
VirtualBMC (with the capital cases) and also fix the README, it changes
the order of "team and repository tag" title to be the last and add
graceful shutdown and NMI as supported commands for ipmitool.
Change-Id: Ieb857b4c1065d5fff2028ee78a4a4e8586cd4724
This patch is restructuring the VirtualBMC repository according to the
OpenStack template for projects (Cookiecutter).
This patch also removes the dependency on the python-daemon library
since it is not present in the OpenStack global-requirements, now a new
class called "detach_process" has been added to the virtualbmc/utils.py
module that will take care of detaching the process context from its
parent and session.
Change-Id: Id4ae1db5b73a18abc54276fe1dfbf3ceff7adc06
Jay Faulkner