infra-specs/specs/deploy-stackviz.rst
Jeremy Stanley 283d14329f Clean up implemented specs
Per discussion in the most recent Infrastructure team meeting:

http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-06-06-19.03.html

...the following specifications should be considered completed and
so are being moved into the implemented subsection of the index:

    complete-reviewable-release-automation
    ethercalc
    neutral-governance-website
    publish-election-repo
    releases-openstack-org
    shade

These specs had some parts which were not completed for various
reasons and became out of scope, so have been adjusted slightly to
stop mentioning the missing features and moved into implemented:

    deploy-stackviz
    unified_mirrors

Change-Id: Ia603a1f752e0c8acb43ed323864267c2b69bdf03
2017-06-07 22:45:57 +00:00

135 lines
3.8 KiB
ReStructuredText

::
Copyright 2015 OpenStack Foundation
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
===============================
Stackviz Deployment
===============================
Story: https://storyboard.openstack.org/story/2000498
Stackviz is a tool for visualizing Tempest gate runs. Presently, the project is
in a stable state under openstack/stackviz. This spec details the process of
getting Stackviz integrated on the build images to run with live data. For the
most up to date information on this process, see:
https://etherpad.openstack.org/p/BKgWlKIjgQ
Problem Description
===================
Stackviz currently exists under openstack/stackviz, and can be downloaded,
built and run against local test run data. The tool provides a timeline,
detailed test view, and traceback logs to help developers easily debug runs
that went wrong. However, this does not provide much utility to OS developers
about their current patches in the gate. For Stackviz to be a truly useful
debugging tool, it must be available on-demand, with little to no config work
on the part of the developer.
Proposed Change
===============
To solve this, we propose that Stackviz be integrated upstream with the
following two-pronged approach:
First, download a copy of Stackviz onto the Nodepool images. The required
npm dependencies will be downloaded and installed, and the static site will
be built. To accomplish this, a new Nodepool DIB element will be made for
the creation of the repository and building of the static site.
Second, copy the site into logs uploaded to the logs server. Additional data
processing at this step will include installing the python processing module
(stackviz-export) and parsing subunit and dstat.csv logs. A configuration file
will be generated for each patch, which will allow the developer to browse a
Stackviz site within each set of logs using their patch's data.
Alternatives
------------
A puppet deployment is another option for consideration (puppet-stackviz).
Traditionally, infra has deployed software via puppet modules and not DIB
elements. Stackviz would be breaking the pattern in this case.
A third-party Stackviz deployer is currently up for testing purposes at:
https://stackviz.timothyb89.org/
This demonstrates another possibility: creating a standalone server that pulls
logs from Gerrit at the request of a user to generate a Stackviz on-the-fly.
More details for this project can be viewed at:
https://etherpad.openstack.org/p/stackviz-deployment
Implementation
==============
Assignee(s)
-----------
Primary assignee:
austin81
Secondary assignee:
timothyb89
Gerrit Topic
------------
Use Gerrit topic "deploy-stackviz" for all patches related to this spec.
.. code-block:: bash
git-review -t deploy-stackviz
Work Items
----------
Currently, there are WIP patches for both parts of the process outlined above:
Nodepool element: https://review.openstack.org/279317/
Devstack-gate patch: https://review.openstack.org/212207/
See https://etherpad.openstack.org/p/BKgWlKIjgQ for more details
Repositories
------------
None
Servers
-------
The Nodepool images will need an additional DIB element to do pre-processing
work for Stackviz. The devstack-gate images will also require an additional
script for creating config files and hosting the sites.
DNS Entries
-----------
None
Documentation
-------------
If implemented correctly, Stackviz should fundamentally change the OS
developer workflow process. Checking the Stackviz site on the logs server
should become the first thing that the developers do once their patch goes
through the gate tests. http://docs.openstack.org/infra/manual/developers.html
will need to be updated.
Security
--------
None
Testing
-------
None
Dependencies
============
https://git.openstack.org/openstack/stackviz