summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDan Callaghan <dcallagh@redhat.com>2014-12-03 11:45:42 +1000
committerDan Callaghan <dcallagh@redhat.com>2014-12-03 16:00:14 +1000
commitb30f203f14f9b2160ceabd7fd9d192150acefb15 (patch)
treebf70332796b685eeb0e47d0f41d20e8bf73df3d2
parentad0cd931fa7226d2fdc1999f3c4132cbe8757dde (diff)
remove Sphinx docs, using Jenkins for publication
Beaker docs are built from Beaker's source tree, using the beaker-project.org Sphinx theme from here. Similarly, dev docs have been extracted into their own git repo and are built from that using the beaker-project.org Sphinx theme. Publication is handled by Jenkins using rsync.
-rw-r--r--.gitmodules37
-rw-r--r--Makefile39
-rw-r--r--README113
m---------beaker-branches/develop0
m---------beaker-branches/master0
m---------beaker-branches/release-0.110
m---------beaker-branches/release-0.120
m---------beaker-branches/release-0.130
m---------beaker-branches/release-0.140
m---------beaker-branches/release-0.150
m---------beaker-branches/release-0.160
m---------beaker-branches/release-0.170
m---------beaker-branches/release-0.180
m---------beaker-branches/release-190
-rw-r--r--dev/bpo.rst97
-rw-r--r--dev/conf.py40
-rw-r--r--dev/guide/cli-guidelines.rst89
-rw-r--r--dev/guide/code-guidelines.rst215
-rw-r--r--dev/guide/development-lifecycle.rst164
-rw-r--r--dev/guide/example-patch.rst147
-rw-r--r--dev/guide/getting-started.rst117
-rw-r--r--dev/guide/index.rst31
-rw-r--r--dev/guide/source-walkthrough.rst235
-rw-r--r--dev/guide/ui-guidelines.rst84
-rw-r--r--dev/guide/virtual-fedora/index.rst436
-rw-r--r--dev/guide/virtual-fedora/scripts/beaker-server-lc.ks59
-rwxr-xr-xdev/guide/virtual-fedora/scripts/create_server_lc_vm.sh14
-rwxr-xr-xdev/guide/virtual-fedora/scripts/setup_db.sh51
-rwxr-xr-xdev/guide/virtual-fedora/scripts/setup_network.sh59
-rwxr-xr-xdev/guide/virtual-fedora/scripts/setup_storage.sh110
-rwxr-xr-xdev/guide/virtual-fedora/scripts/setup_test_system.sh123
-rw-r--r--dev/guide/what-to-work-on.rst24
-rw-r--r--dev/guide/writing-a-patch.rst258
-rw-r--r--dev/index.rst18
-rw-r--r--dev/proposals/README2
-rw-r--r--dev/proposals/access-policies-for-systems.rst164
-rw-r--r--dev/proposals/beaker-usage-report-emails.rst123
-rw-r--r--dev/proposals/custom-distros.rst161
-rw-r--r--dev/proposals/dynamic-virtualization.rst201
-rw-r--r--dev/proposals/effective-job-priorities.rst134
-rw-r--r--dev/proposals/enhanced-user-groups.rst554
-rw-r--r--dev/proposals/event-driven-scheduler.rst263
-rw-r--r--dev/proposals/external-tasks.rst186
-rw-r--r--dev/proposals/handling-large-installations.rst211
-rw-r--r--dev/proposals/harness-api.rst321
-rw-r--r--dev/proposals/index.rst106
-rw-r--r--dev/proposals/inventory-lshw-migration.rst119
-rw-r--r--dev/proposals/reference-harness.rst88
-rw-r--r--dev/proposals/system-page-improvements-screenshots/details-tab.pngbin99543 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/essentials-tab.pngbin96256 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/lend-modal.pngbin76447 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/loan-tab.pngbin84186 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/owner-tab.pngbin84270 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/provision-tab.pngbin86871 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/reserve-workflow.pngbin54480 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/scheduler-tab.pngbin106658 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements-screenshots/system-page-0.14.pngbin120582 -> 0 bytes
-rw-r--r--dev/proposals/system-page-improvements.rst313
-rw-r--r--dev/proposals/system-pools.rst154
-rw-r--r--dev/proposals/time-limited-manual-reservations.rst127
-rw-r--r--dev/proposals/time-limited-system-loans.rst109
-rw-r--r--dev/related-projects.rst45
-rw-r--r--dev/tech-roadmap.rst462
-rw-r--r--docs/conf.py32
-rwxr-xr-xgenerate-docs-mk.sh28
-rwxr-xr-xpublish.sh86
66 files changed, 18 insertions, 6531 deletions
diff --git a/.gitmodules b/.gitmodules
deleted file mode 100644
index a3bbbe4..0000000
--- a/.gitmodules
+++ /dev/null
@@ -1,37 +0,0 @@
-[submodule "beaker-branches/develop"]
- path = beaker-branches/develop
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/master"]
- path = beaker-branches/master
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/release-0.11"]
- path = beaker-branches/release-0.11
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/release-0.12"]
- path = beaker-branches/release-0.12
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/release-0.13"]
- path = beaker-branches/release-0.13
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/release-0.14"]
- path = beaker-branches/release-0.14
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/release-0.15"]
- path = beaker-branches/release-0.15
- url = git://git.beaker-project.org/beaker
-[submodule "beaker-branches/release-0.16"]
- path = beaker-branches/release-0.16
- url = git://git.beaker-project.org/beaker
- branch = release-0.16
-[submodule "beaker-branches/release-0.17"]
- path = beaker-branches/release-0.17
- url = git://git.beaker-project.org/beaker
- branch = release-0.17
-[submodule "beaker-branches/release-0.18"]
- path = beaker-branches/release-0.18
- url = git://git.beaker-project.org/beaker
- branch = release-0.18
-[submodule "beaker-branches/release-19"]
- path = beaker-branches/release-19
- url = git://git.beaker-project.org/beaker
- branch = release-19
diff --git a/Makefile b/Makefile
index e265d75..8fdec9c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,28 +1,19 @@
SHELL = /bin/bash
-BEAKER = beaker-branches/master
-BEAKER_GIT = .git/modules/beaker-branches/master
-SPHINXBUILD = $(shell command -v sphinx-1.0-build sphinx-build)
-SPHINXBUILDOPTS =
+BEAKER = ../beaker
+BEAKER_GIT = $(BEAKER)/.git
# Symbolic targets defined in this Makefile:
-# all-docs: all branches of the Sphinx docs from Beaker git
# all-website: all the web site bits, *except* yum repos
# all: all of the above, plus yum repos
.PHONY: all
-all: all-docs all-website yum
+all: all-website yum
include downloads.mk
include old-downloads.mk
include changelogs.mk
-include docs.mk # defines all-docs target
-
-# treat warnings as errors only for the released docs
-docs: SPHINXBUILDOPTS += -W
-
.PHONY: all-website
all-website: \
- dev \
releases/SHA1SUM \
releases/index.html \
releases/index.atom \
@@ -34,31 +25,17 @@ all-website: \
in-a-box/beaker-distros.html \
in-a-box/beaker-virt.html \
-docs.mk: beaker-branches generate-docs-mk.sh
- ./generate-docs-mk.sh >$@
-
-.PHONY: dev
-dev: SPHINXBUILDOPTS += -W
-dev:
- $(SPHINXBUILD) $(SPHINXBUILDOPTS) -c $@ -b html ./dev/ $@/
-
-.PHONY:
-git-rev-beaker-master:
- read old_sha <$@ ; \
- new_sha=$$(git ls-tree HEAD beaker-branches/master | awk '{ print $$3 }') && \
- if [[ $$old_sha != $$new_sha ]] ; then echo $$new_sha >$@ ; fi
-
-downloads.mk: git-rev-beaker-master generate-downloads-mk.py git_tags.py
+downloads.mk: generate-downloads-mk.py git_tags.py
./generate-downloads-mk.py $(BEAKER_GIT) >$@
-changelogs.mk: git-rev-beaker-master generate-changelogs-mk.py git_tags.py
+changelogs.mk: generate-changelogs-mk.py git_tags.py
./generate-changelogs-mk.py $(BEAKER_GIT) >$@
-releases/index.html: git-rev-beaker-master releases/SHA1SUM generate-releases-index.py git_tags.py docs
+releases/index.html: releases/SHA1SUM generate-releases-index.py git_tags.py
mkdir -p $(dir $@)
./generate-releases-index.py --format=html $(BEAKER_GIT) >$@
-releases/index.atom: git-rev-beaker-master releases/SHA1SUM generate-releases-index.py git_tags.py
+releases/index.atom: releases/SHA1SUM generate-releases-index.py git_tags.py
mkdir -p $(dir $@)
./generate-releases-index.py --format=atom $(BEAKER_GIT) >$@
@@ -103,4 +80,4 @@ check:
./check-yum-repos.py
clean:
- rm -f changelogs.mk docs.mk downloads.mk releases/SHA1SUM releases/index.* in-a-box/*.html
+ rm -f changelogs.mk downloads.mk releases/SHA1SUM releases/index.* in-a-box/*.html
diff --git a/README b/README
index bf71223..0dfa3ee 100644
--- a/README
+++ b/README
@@ -1,117 +1,24 @@
This is the beaker-project.org web site.
-Note that many parts of this web site are generated from elsewhere:
+Note that many parts of the web site are built elsewhere:
- * Some documentation is built using Sphinx from docstrings extracted
- from Beaker code.
- * Some shell scripts have a pretty documented version which is
- generated by shocco.
+ * Beaker documentation (under the docs/ and docs-<branch>/ subdirectories)
+ is built using Sphinx from the documentation/ subdirectory of Beaker's
+ source tree.
+ * Beaker developer documentation (under the dev/ subdirectory) is built
+ from a separate source repository.
-This repository uses git submodules to include all (recent) branches of
-Beaker's source tree under the beaker-branches/ subdirectory. On first checkout
-you should initialise the submodules by running:
+The process for submitting patches is the same as for Beaker itself:
- git submodule init
+ https://beaker-project.org/dev/guide/writing-a-patch.html#submitting-your-patch
-and subsequently update them by running:
-
- git submodule update
-
-These commands should be rerun after each new Beaker release to pick up
-the new submodule.
-
-Running ./update-submodules.sh will update the submodules to the latest
-version of their respective branches. Don't forget to git commit and git
-push after doing so! (Unlike most other changes, submodule updates may be
-pushed directly to the central git server)
-
-Caching large files
--------------------
-
-Run make in the root directory to ensure large files are cached locally.
-Otherwise each publication attempt will download all the tarballs and
-RPMs.
+Publishing the live version of the web site on beaker-project.org is handled by
+an internal Jenkins job managed by the Beaker development team.
Dependencies
------------
-* python-sphinx
* python-dulwich (to generate release changelogs)
* rubygem-rdiscount ( to install markdown for shocco)
-
-Building docs from a local checkout
------------------------------------
-
-The web site builds the Sphinx documentation from each submodule in
-beaker-branches/ as docs-$BRANCHNAME/ (master is just docs/).
-
-If you want to also build the docs from your own Beaker checkout with random
-modifications, you can trick the scripts into thinking it is a separate branch
-named "mine":
-
- ln -s ../../path/to/your/beaker beaker-branches/mine
-
-Then you can build it as docs-mine:
-
- make docs-mine
-
-
-Making changes to the web site
-------------------------------
-
-If any branches of Beaker have moved on (because a new version of Beaker has
-been released), update their submodule reference. XXX pester Dan to automate
-this. For example, to update master:
-
- cd beaker-branches/master
- git pull origin master
- cd ../..
- git add -u beaker-branches/master
- git commit -m 'update beaker master submodule'
-
-Commit any changes you have to your local master branch. Any changes that you
-make should be verified locally. This includes document changes, repo
-changes etc. To do this, run `make` and then the following (unless
-you have alternative HTTP server configured for this process):
-
- python -m SimpleHTTPServer 8000
-
-You can now check your changes against 'http://localhost:8000'.
-Once the changes have been verified you should push them to Beaker's gerrit
-instance (See the 'Submitting your patch' section in the developer guide
-for instructions on how to setup a gerrit remote):
-
- git push gerrit master:refs/for/master
-
-As an alternative, you can send your patch to
-beaker-devel@lists.fedorahosted.org.
-
-Once your patch has been merged, and if you have access to publish to
-beaker-project.org, you can now publish the change. If you don't have
-access, thank you for the patch and one of the Beaker developers will
-publish it for you.
-
-
-Publishing changes to the web site
-----------------------------------
-
-The first step in publishing is to build your changes:
-
- ./publish.sh
-
-Now the 'published' branch has been updated. First, check that the
-changes you've introduced look sane:
-
- git diff published~..published
-
-If the diff looks incorrect (for example, you accidentally ran `./publish.sh`
-before running `git pull` or commiting a change), discard the unwanted
-publication attempt:
-
- git fetch beaker-project.org:/srv/www/beaker-project.org/git/ +master:published
-
-If you're happy with it, push it live:
-
- git push beaker-project.org:/srv/www/beaker-project.org/git/ published:master
diff --git a/beaker-branches/develop b/beaker-branches/develop
deleted file mode 160000
-Subproject 06785371d8cbce12a7af5358af458822e8eea18
diff --git a/beaker-branches/master b/beaker-branches/master
deleted file mode 160000
-Subproject 22c666aafa4b802dcf21c662439e5f444e86a73
diff --git a/beaker-branches/release-0.11 b/beaker-branches/release-0.11
deleted file mode 160000
-Subproject cea656822da00a3510cbb9762546a588d329e99
diff --git a/beaker-branches/release-0.12 b/beaker-branches/release-0.12
deleted file mode 160000
-Subproject e823f48459d736afbaaffe87ae73dce7355af0c
diff --git a/beaker-branches/release-0.13 b/beaker-branches/release-0.13
deleted file mode 160000
-Subproject 4473c9bdda299242a2f54bfba2b6d36fd0dbefc
diff --git a/beaker-branches/release-0.14 b/beaker-branches/release-0.14
deleted file mode 160000
-Subproject 4b878139d3f7e427d0d4bdac7d274935074c5be
diff --git a/beaker-branches/release-0.15 b/beaker-branches/release-0.15
deleted file mode 160000
-Subproject 4190c3134177776bc7bded55c8dc0f42ea177a5
diff --git a/beaker-branches/release-0.16 b/beaker-branches/release-0.16
deleted file mode 160000
-Subproject 363fd4b6d0bdc290af480437029f71ada2bfdde
diff --git a/beaker-branches/release-0.17 b/beaker-branches/release-0.17
deleted file mode 160000
-Subproject a3624c59d6de6d55cfc2c6ab0c234131bd18825
diff --git a/beaker-branches/release-0.18 b/beaker-branches/release-0.18
deleted file mode 160000
-Subproject a6d30eda1286e658779a1fd6c296e4df4130d77
diff --git a/beaker-branches/release-19 b/beaker-branches/release-19
deleted file mode 160000
-Subproject 7bf18d8adcc745d0423219c219e9078d3d97b1b
diff --git a/dev/bpo.rst b/dev/bpo.rst
deleted file mode 100644
index 65429cb..0000000
--- a/dev/bpo.rst
+++ /dev/null
@@ -1,97 +0,0 @@
-Maintaining the beaker-project.org infrastructure
-=================================================
-
-This document describes the configuration and upgrade procedures for the host
-running beaker-project.org. If you just want to update the web site at
-http://beaker-project.org/ see its `README
-<http://git.beaker-project.org/cgit/beaker-project.org/tree/README>`__.
-
-Configuration management
-------------------------
-
-The contents of ``/etc`` are tracked using `etckeeper
-<http://joeyh.name/code/etckeeper/>`_. After making config changes, run
-``etckeeper commit`` to record them.
-
-Remote access
--------------
-
-Remote access is by SSH key authentication only. Speak to a Beaker developer if
-you need a user account to be created.
-
-Lighttpd
---------
-
-Lighttpd listens on port 80 and serves all web traffic for
-\*.beaker-project.org. SSL on port 443 is disabled since we do not have any SSL
-certificates.
-
-The base config is in the standard place (``/etc/lighttpd/lighttpd.conf``).
-Config for each name-based virtual host is included from the corresponding file
-in ``/etc/lighttpd/vhosts.d/``.
-
-At present, a custom rebuild of the lighttpd package is installed to fix `bug
-912546 <https://bugzilla.redhat.com/show_bug.cgi?id=912546>`_. Make sure not to
-upgrade/downgrade to a version of the package which is not patched (for
-example, when upgrading to a new Fedora release).
-
-Git daemon
-----------
-
-The git daemon serves read-only git repos on port 9418.
-
-At present the Fedora package for git-daemon uses xinetd, but we are running it
-as a systemd service instead (defined in
-``/etc/systemd/system/git-daemon.service``).
-
-Tomcat
-------
-
-Tomcat listens on port 8080 to serve the Gerrit application. This port is not
-open to the world, it is proxied by the gerrit.beaker-project.org vhost in
-lighttpd. Gerrit also listens on port 29418 for its fake SSH service.
-
-Note that we are *not* using Gerrit's control script ``gerrit.sh`` and we are
-*not* running the embedded Jetty container.
-
-There is no standard way to install or upgrade Java web apps so the following
-layout has been devised. Gerrit WARs are kept in ``/var/lib/gerrit``. Gerrit
-"site directories" are kept underneath that path. There is one site, named
-beaker. So the "site path" (as mentioned in the Gerrit docs) is
-``/var/lib/gerrit/beaker``. The ``etc`` directory for the Gerrit site is then
-symlinked to ``/etc/gerrit/beaker``, so that it is tracked by etckeeper.
-
-Tomcat's ``/etc/tomcat/server.xml`` file defines one virtual host,
-gerrit.beaker-project.org, with applications stored in
-``/var/lib/tomcat/gerrit-webapps``. The ROOT application for that virtual host
-is then symlinked to the WAR inside the Gerrit site path.
-
-To upgrade Gerrit, follow these steps::
-
- cd /var/lib/gerrit
- wget https://gerrit-releases.storage.googleapis.com/gerrit-2.6.1.war
- java -jar gerrit-2.6.1.war init -d beaker
-
-The upgrade process first prompts for settings. You can accept all defaults --
-the defaults are the existing configuration. Then it will perform any necessary
-schema upgrades.
-
-Also check that the permissions and ownership of
-``/etc/gerrit/beaker/secure.config`` have not been overwritten (it must be
-owned root:tomcat with mode 0640).
-
-Finally, force Tomcat to unpack the new WAR::
-
- systemctl stop tomcat.service
- rm -rf /var/lib/tomcat/gerrit-webapps/ROOT/
- systemctl start tomcat.service
-
-SMTP
-----
-
-Postfix accepts mails for beaker-project.org on port 25 (as well as relaying
-from localhost, e.g. Gerrit notifications).
-
-All user accounts (including root) have a mail alias in ``/etc/aliases``
-pointing to their real address. No mail should ever be delivered to the local
-system.
diff --git a/dev/conf.py b/dev/conf.py
deleted file mode 100644
index da54287..0000000
--- a/dev/conf.py
+++ /dev/null
@@ -1,40 +0,0 @@
-
-extensions = [
- 'sphinx.ext.intersphinx',
- 'sphinx.ext.todo',
- 'sphinxcontrib.httpdomain',
-]
-master_doc = 'index'
-project = u'Beaker'
-copyright = u'2013, Red Hat, Inc'
-
-release = version = "Project"
-
-html_title = 'Beaker development'
-html_use_index = False
-html_domain_indices = False
-html_theme = 'beaker'
-html_theme_path = ['../sphinx-theme']
-
-intersphinx_mapping = {
- 'python': ('http://docs.python.org/', '../python-intersphinx.inv'),
- 'sqlalchemy': ('http://docs.sqlalchemy.org/en/rel_0_7/', '../sqlalchemy-intersphinx.inv'),
-}
-
-# This config is also a Sphinx extension with some Beaker-specific customisations:
-
-import docutils.core, docutils.nodes
-
-# A poor man's version of sphinxcontrib-issuetracker
-# <https://pypi.python.org/pypi/sphinxcontrib-issuetracker> which unfortunately
-# requires a newer python-requests than is available in Fedora.
-# This code inspired by Doug Hellman's article
-# <http://doughellmann.com/2010/05/defining-custom-roles-in-sphinx.html>.
-def beaker_bugzilla_issue_role(name, rawtext, text, lineno, inliner, options={}, content=[]):
- bz_url = 'https://bugzilla.redhat.com/show_bug.cgi?id=%s' % text
- text = "#" + text
- node = docutils.nodes.reference(rawtext, text, refuri=bz_url, **options)
- return [node], []
-
-def setup(app):
- app.add_role('issue', beaker_bugzilla_issue_role)
diff --git a/dev/guide/cli-guidelines.rst b/dev/guide/cli-guidelines.rst
deleted file mode 100644
index 4179671..0000000
--- a/dev/guide/cli-guidelines.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-
-.. _cli-guidelines:
-
-Command line interface guidelines
-=================================
-
-.. note::
-
- Much of Beaker's command line interface may not currently meet
- these guidelines, due to historical inconsistencies.
- These guidelines are for new code.
-
-Writing in Python
------------------
-
-Scripts should always be written in Python. The :py:mod:`optparse` module
-should be used, as Beaker is written for Python 2.6 on Red Hat Enterprise Linux
-6 and derivatives.
-
-When adding a new command to beaker client create a new module in the
-:py:mod:`bkr.client.commands` package, using an existing module as a guideline.
-
-When writing server side scripts, a module should be created in the
-:py:mod:`bkr.server.tools` package and then added to the ``console_scripts``
-key in :file:`Server/setup.py`. Always prepend ``beaker-`` to the name of the
-script. The ``%files server`` section in :file:`beaker.spec` will need to be
-updated as well, see the existing entries for the correct way to do this.
-
-The above guidelines apply for scripts written for the lab controller as well,
-except the ``console_scripts`` key is updated in the
-:file:`LabController/setup.py` file and the ``%files lab-controller`` section
-of :file:`beaker.spec` needs to be modified.
-
-
-Comply with POSIX standards
----------------------------
-
-Endeavour to stick to the `GNU standards <http://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html>`_
-unless there is a good reason not to or anything in this guide expressly goes
-against it.
-
-
-Output
-------
-
-The primary goal of Beaker's CLI utilities are
-for interfacing with scripts for the purposes of automation.
-
-To this end, these utilities' defaults should be geared around this.
-If an operation is mutative, no output should be printed to stdout.
-If an operation is selective, machine readable output should be
-printed to stdout (i.e JSON).
-
-An exit code of zero indicates success, non-zero on failure.
-
-These utilities are also often used by humans and so human
-readable output is also highly desired. If there is no default output, than
-make sure that the ``--verbose`` option is usable, and gives sensible and
-appreciable output for human consumption. If the default output is designed to
-be machine readable, then make sure there is a more human friendly option for
-``--format``.
-
-Whenever it is practical to implement, CLI users should not see Python
-tracebacks for things that we anticipate them getting wrong, as the traceback
-is just irrelevant noise in that situation. Instead, the CLI should catch the
-relevant exception, display a clear message on stderr that explains what went
-wrong (and ideally how to fix it), and then exit with a non-zero return code.
-
-The argument parsing library automatically takes care of this for many simpler
-user errors, and the client command framework should automatically handle it
-for authentication errors and most server side data validation and access
-control errors.
-
-This CLI requirement also impacts the server code handling HTTP requests, as it
-usually means that an appropriate exception should be raised in Beaker itself,
-rather than allowing exceptions from library code to cascade up to the web
-framework and hence on to the CLI user. The
-:py:func:`bkr.server.flask_util.convert_internal_errors` context manager is
-provided specifically for this purpose.
-
-However, care needs to be taken not to hide genuine programming errors by
-misreporting them as errors in the user's input.
-
-
-Backwards compatibility
------------------------
-
-Beaker's CLI is considered an API. See :ref:`api-stability`
-regarding Beaker's policy on changing and designing APIs.
diff --git a/dev/guide/code-guidelines.rst b/dev/guide/code-guidelines.rst
deleted file mode 100644
index 52c5145..0000000
--- a/dev/guide/code-guidelines.rst
+++ /dev/null
@@ -1,215 +0,0 @@
-Coding guidelines
-=================
-
-This page summarizes some of the guidelines that should be helpful
-while adding new code to Beaker.
-
-Model
-~~~~~
-
-From version 0.16 onwards, Object Relational Mapped classes should be defined
-`declaratively
-<http://docs.sqlalchemy.org/en/rel_0_7/orm/extensions/declarative.html>`__. Previous
-versions used `Classical Mapping
-<http://docs.sqlalchemy.org/en/rel_0_7/orm/mapper_config.html#classical-mappings>`__
-for some classes.
-
-Some basic guidelines to follow when modifying model:
-
-- Commonly used queries should be encapsulated as class methods of the
- respective classes or using `hybrid attributes
- <http://docs.sqlalchemy.org/en/rel_0_7/orm/extensions/hybrid.html>`__.
-- Enumerated types should be defined as type DeclEnum and not be
- described in a database schema. This helps avoid over normalization,
- cuts down on unnecessary calls to the database, and reduces the
- likelihood of complex joins that confuse the query optimizer. This
- only applies though if it's an enumeration that is static.
-- When writing queries, use ORM attributes over `SQL Expression
- Language
- <http://docs.sqlalchemy.org/en/rel_0_7/core/tutorial.html?highlight=sql%20expression%20language>`__
- whenever possible, and never use `Text <http://docs.sqlalchemy.org/en/rel_0_7/core/types.html>`__.
-- Write efficient queries. Do what you can to write the most reasonably
- efficient query. For various reasons, Beaker has few options of
- removing its historical data. Thus, dataset can only increase in size
- over time. As Beaker's UI relies heavily on database
- calls, writing inefficient queries can quickly become a bottleneck
- and create a marked reduction in usability.
-- Beyond the basic relationship mapping, relationships should be
- defined keeping performance in mind. The sqlalchemy documentation
- provides some good
- `ideas <http://docs.sqlalchemy.org/en/rel_0_7/orm/collections.html>`_.
-- Remember to define relevant cascade options.
-
-
-Database column defaults
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-For database columns with `default values
-<http://docs.sqlalchemy.org/en/rel_0_7/core/schema.html#column-insert-update-defaults>`__,
-always use a Python-level default: pass a scalar or Python callable as the
-*default* parameter for the :py:class:`Column() <sqlalchemy.schema.Column>`
-constructor.
-
-Note that this means the default value will *not* appear on the column
-definition in the database schema. Schema upgrade notes which add a new column
-with a default value should look like this (note no ``DEFAULT`` clause)::
-
- ALTER TABLE power ADD COLUMN power_quiescent_period INT NOT NULL;
- UPDATE power SET power_quiescent_period = 5;
-
-Do not use server-side column defaults (*server_default* parameter, or
-*default* with a SQL expression). That way we avoid defining the default value
-in two places (model code and the database schema); Beaker can skip the extra
-database round-trip to fetch the generated defaults, which might be expensive
-in some cases; and we have one consistent mechanism for defining column
-defaults throughout the application.
-
-
-Database migrations
-~~~~~~~~~~~~~~~~~~~
-
-Starting with Beaker 0.18, the Beaker server uses Alembic to manage database
-migrations. The migrations in the alembic/versions contain the changes needed
-to migrate from older beaker releases to newer versions. A migration occurs
-by executing a script that details the changes needed to upgrade/downgrade the
-database. The migration scripts are ordered so that multiple scripts can run
-sequentially to update the database. The scripts are executed by beaker-init
-which uses the Alembic library to manage the migration.
-
-A database migration script is required when you submit a change to beaker
-that alters the database model definition. The migration script is a special
-python file that includes code to update/downgrade the database to match the
-changes in the model definition. Alembic will execute these scripts in order to
-provide a linear migration path between revision::
-
- $ PYTHONPATH=../Common:. python -c '__requires__ = ["CherryPy < 3.0"]; \
- import pkg_resources; from bkr.log import log_to_stream; import sys; \
- from bkr.server.util import load_config;from alembic.config import main; \
- import logging; log_to_stream(sys.stderr, level=logging.INFO); \
- load_config(); main()' -c alembic.ini \
- revision --autogenerate -m "description of revision"
-
-This generates a prepopulated template with the changes needed to match the
-database state with the models(your working directory should be the Server
-subdirectory of your local clone of the main beaker project). You should inspect
-the autogenerated template to ensure that the proper models have been altered.
-Please see Alembic's documentation for full detail including caveats and limitations.
-
-In rare circumstances, you may want to start with an empty migration template
-and manually author the changes necessary for an upgrade/downgrade. You can
-create a blank file via::
-
- $ PYTHONPATH=../Common:. python -c '__requires__ = ["CherryPy < 3.0"]; \
- import pkg_resources; from bkr.log import log_to_stream; import sys; \
- from bkr.server.util import load_config;from alembic.config import main; \
- import logging; log_to_stream(sys.stderr, level=logging.INFO); \
- load_config(); main()' -c alembic.ini \
- revision -m "description of revision"
-
-To upgrade the database to the latest version::
-
- $ beaker-init
-
-To downgrade the database by a revision identifier::
-
- $ beaker-init --downgrade <revision-identifier>
-
-
-Controller methods
-~~~~~~~~~~~~~~~~~~
-
-Starting with Beaker 0.15, the Beaker server uses Flask. The Flask
-application instance, ``app`` needs to be imported from ``bkr.server.app``
-and then the view function can be exposed by decorating it with
-``@app.route()``. You can also specify the HTTP methods which the view can
-handle using the methods keyword argument. Example::
-
- @app.route('/systems/<fqdn>/access-policy', methods=['POST','PUT'])
-
-To learn more about Flask routing, see `here
-<http://flask.pocoo.org/docs/api/#url-route-registrations>`__.
-
-CherryPy is embedded inside Flask to support the large number of
-legacy TurboGears controllers which still exist in Beaker. New code
-should not use TurboGears or CherryPy unless necessary.
-
-In most controller methods, you may need to perform one or more of the
-following functions:
-
-- *Authentication*: If a view function requires authentication, it should
- be decorated using the ``bkr.server.flask_util.auth_required``
- decorator (added in Beaker 0.15.2).
-
-- *Returning data*: Use Flask's ``jsonify()`` function to return your response
- as JSON objects. To learn more, see `here
- <http://flask.pocoo.org/docs/api/#module-flask.json>`__.
-
-- *Aborting*: If something is not right, raise an appropriate
- exception from one of the exception classes defined in
- ``bkr.server.flask_util`` (starting with Beaker 0.15.2). For
- example, ``raise NotFound404('System not found')``. If an
- appropriate exception is not found, please add one in this module
- along with your patch.
-
-- *Empty response*: If the view function has nothing to return,
- return an empty string with a status code, like so: ``return '',
- 204``.
-
-.. _api-stability:
-
-API compatibility
-~~~~~~~~~~~~~~~~~
-
-To avoid unnecessary churn for our users, Beaker maintains API compatibility
-across all maintenance releases in a series (for example 19.0, 19.1, …). Any
-patches in a maintenance release must not break API compatibility.
-
-APIs can be removed (if absolutely necessary) only after they have been through
-a deprecation period of at least one release. This entails updating all
-relevant documentation and code to mark the API as deprecated in version N, and
-then removing it no sooner than version N+1.
-
-These guidelines apply specifically to (programmatic) HTTP interfaces, XML-RPC
-interfaces, and the bkr client.
-
-Client–server compatibility
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The bkr client must be backwards compatible with at least the previous version
-of the server (for example, client 20.x must be compatible with server 19.x).
-New commands are excluded from this requirement.
-
-Also note that the bkr client itself is considered an API for scripting
-purposes, so it must also maintain API compatibility with older versions of
-itself as described above.
-
-Logging Activities
-~~~~~~~~~~~~~~~~~~
-
-If an activity needs to be logged, use the ``ActivityMixin`` methods to
-record it. For example::
-
- system.record_activity(user=identity.current.user,
- service=u'HTTP',field=u'Access Policy Rule', action=u'Removed')
-
-
-However, for this to be possible, the ORM class should inherit the
-``ActivityMixin`` class and define an ``activity_type`` attribute set
-to the ``Activity`` subclass to use, like so::
-
- class User(MappedObject, ActivityMixin):
- @property
- def activity_type(self):
- return UserActivity
- # class definition
-
-Writing tests
-~~~~~~~~~~~~~
-
-The `unittest2 <https://pypi.python.org/pypi/unittest2>`__ package
-adds a number of additional convenience methods and hence should be
-preferred for new tests. All existing and new tests should import it
-as : ``import unittest2 as unittest``.
-
-New selenium tests should use ``webdriver`` via
-``WebDriverTestCase``.
diff --git a/dev/guide/development-lifecycle.rst b/dev/guide/development-lifecycle.rst
deleted file mode 100644
index 4e5d22c..0000000
--- a/dev/guide/development-lifecycle.rst
+++ /dev/null
@@ -1,164 +0,0 @@
-.. _dev-lifecycle:
-
-Development lifecycle
-=====================
-
-Beaker's overall development is tracked in `Bugzilla`_. Bugs which have been
-accepted by the core development team as desirable features or fixes to
-include in Beaker 1.0 (or an earlier minor or maintenance release) will
-have an assigned target milestone. Other open Bugzilla entries are either
-still under investigation, or remain under consideration for implementation
-in a version following the 1.0 release.
-
-.. _Bugzilla: https://bugzilla.redhat.com/page.cgi?id=browse.html&product=Beaker&product_version=&bug_status=open&tab=summary
-
-
-Release numbering and branching model
--------------------------------------
-
-The target scope of the overall 1.0 release is described in the Beaker
-:ref:`technical road map <technical-roadmap>` and the
-:ref:`proposal-handling-large-installations` design proposal. The number
-and scope of the individual minor 0.x releases leading up to the eventual
-1.0 major release are quite fluid, as is the number of maintenance
-releases made for each minor release.
-
-
-Minor releases
-~~~~~~~~~~~~~~
-
-Minor releases are built around :ref:`design-proposals`. These proposals are
-for relatively large chunks of functionality, which may end up being
-delivered across multiple minor releases.
-
-In general, the core development team will nominate a particular design
-proposal as the current focus of development for a minor release, and the
-release will not be published until a meaningful portion of the design
-proposal has been completed.
-
-Development aimed at the next minor release takes place on the ``develop``
-branch in git.
-
-For the main Beaker project, when a minor release is considered ready for
-publication, an appropriate ``release-X.Y`` branch is created and a
-release candidate published from the branch. If the release candidate
-passes acceptance testing, then the release branch is merged to
-``master`` and published as the latest version of Beaker.
-
-Once a minor release is published, its release branch becomes the active
-release branch and is used for the creation of any maintenance releases,
-while the ``develop`` branch begins to be used for development of the
-next minor release.
-
-Smaller subprojects, such as the beah test harness and the
-beaker-system-scan hardware scanning utility use a simpler branching
-model where releases are tagged and created directly on the ``develop``
-branch. Maintenance releases are never published for these subprojects -
-any issues are resolved by publishing a new minor release.
-
-The target minor release cadence for the main Beaker project is a new
-minor release every 6-8 weeks. For other subprojects, new minor releases
-are made as needed to resolve issues.
-
-
-Maintenance releases
-~~~~~~~~~~~~~~~~~~~~
-
-As minor releases are based around delivering particular pieces of
-functionality, their exact delivery schedule is necessarily somewhat
-flexible. To ensure that fixes for hardware and installer compatibility
-issues can be incorporated in a timely manner, even if a minor release
-is delayed, all such changes are first included in the active release branch
-and then merged forward to the ``develop`` branch rather than being
-merged directly into ``develop`` in Gerrit.
-
-Whenever the active release branch has accumulated a reasonable number of
-changes and a new minor release isn't about to be published, then a new
-maintenance release will be created and published from the active release
-branch.
-
-There are two major requirements for a change to be considered acceptable
-for inclusion in a maintenance release (and hence included in the active
-release branch rather than the ``develop`` branch):
-
-* it must be possible to deploy it without a significant system outage (in
- particular, this means database schema changes are not permitted in
- maintenance releases)
-* it must not have a broad impact on other parts of the system (for example,
- adding a new client command is acceptable in a maintenance release, as
- those are relatively independent pieces of functionality).
-
-As only relatively small, functionally independent changes are made in
-maintenance releases, these releases are published directly, without a
-preceding release candidate.
-
-
-.. note::
-
- As an exception to the normal approach, there are currently two
- active release branches: ``release-0.14`` and ``release-0.15``.
- This is due to some issues encountered in the initial 0.15 release
- which resulted in the resumption of further maintenance releases for
- 0.14 while the problems with 0.15 were addressed. The current policy
- of always merging changes that would be eligible for a maintenance
- release into the active release branch is a direct result of the
- problematic 0.15 release - if this policy had been in place while 0.15
- was in development, then the initial 0.15 release would likely have
- been delayed while 0.14.2 was released instead.
-
-
-Determining the scope of releases
----------------------------------
-
-As noted above, a single design proposal is typically nominated as the
-release focus for a given minor release. That design proposal will then
-describe the primary user facing change to be included in that release.
-
-Each such design proposal will include a "Deferred Features" section,
-for components which are deliberately *not* being implemented until after
-we have received feedback from users on the initial approach.
-
-At any given point in time, a definite focus will only be chosen for the
-currently in development minor release, and potentially the next
-minor release.
-
-While a tentative focus will also be identified for subsequent releases,
-it is strictly provisional, as user feedback may lead to deferred features
-from earlier design proposals being given precedence, and detailed design
-on the tentative features may identify a need to break them down into
-smaller features implemented across multiple releases.
-
-As there are limits to the number of developers that can effectively work
-on implementing a single design proposal, the release focus is not the
-*sole* change that will be made in a given release - it is merely the one
-that is expected to require the most active engagement from Beaker users
-in order to come up with a good design. The need for active user
-engagement is also the reason for restricting each release to one major
-design update - collecting and incorporating feedback takes time, and
-trying to have too many such discussions at once will not lead to good
-solutions.
-
-At the very least, bug fixes and other minor enhancements will be
-worked on as needed and as time allows. Quality improvements, external
-collaboration and preparatory work for subsequent major features may
-also lead to the inclusion of other more significant changes that are
-not directly related to the release focus.
-
-If such changes qualify for inclusion in a maintenance release, that's
-where they will be implemented. This approach means that, while working on
-each new minor release, one or more maintenance releases will typically be
-published from the active release branch (the exact number will depend on
-when the next minor release is judged to be ready for production use).
-
-The "Target Milestone" field in Bugzilla indicates when a particular change
-is expected to be incorporated and published.
-
-The final authority on the scope of any given release is the Red Hat
-appointed Beaker Development Lead. The major factors currently driving
-prioritisation decisions are:
-
-* Enabling and incorporating external contributions
-* Improving the usability and maintainability of Beaker installations
-* Making `beaker.fedoraproject.org <http://beaker.fedoraproject.org>`__
- an effective tool for Fedora QA
-* Other Red Hat internal requirements
diff --git a/dev/guide/example-patch.rst b/dev/guide/example-patch.rst
deleted file mode 100644
index 984f0c4..0000000
--- a/dev/guide/example-patch.rst
+++ /dev/null
@@ -1,147 +0,0 @@
-An example patch: Group name length validation
-==============================================
-
-.. highlight:: diff
-
-To get a better sense of how the different modules come together, let's
-look at parts of a real patch that has been applied to Beaker. The
-`bug <http://bugzilla.redhat.com/show_bug.cgi?id=990349>`_ concerns
-inconsistencies in the validation of the group name length and
-inconsistency between the database and the validators.
-
-The group name length was increased to 256 instead of 16 with the
-following change in ``model.py``::
-
- diff --git a/Server/bkr/server/model.py b/Server/bkr/server/model.py
- index 1d92142..023896a 100644
- --- a/Server/bkr/server/model.py
- +++ b/Server/bkr/server/model.py
- @@ -1855,7 +1855,7 @@ class Group(DeclBase, MappedObject, ActivityMixin):
- __table_args__ = {'mysql_engine': 'InnoDB'}
-
- group_id = Column(Integer, primary_key=True)
- - group_name = Column(Unicode(16), unique=True, nullable=False)
- + group_name = Column(Unicode(255), unique=True, nullable=False)
- display_name = Column(Unicode(255))
- _root_password = Column('root_password', String(255), nullable=True,
- default=None)
-
-In ``group.py``, the TurboGears validators were updated to retrieve the column
-length from the class definition instead of using hard coded values::
-
- diff --git a/Server/bkr/server/group.py b/Server/bkr/server/group.py
- index cab7d27..da693a4 100644
- --- a/Server/bkr/server/group.py
- +++ b/Server/bkr/server/group.py
- @@ -38,8 +38,12 @@ def set_response(self):
- response.headers['content-type'] = 'application/json'
-
- class GroupFormSchema(validators.Schema):
- - display_name = validators.UnicodeString(not_empty=True, max=256, strip=True)
- - group_name = validators.UnicodeString(not_empty=True, max=256, strip=True)
- + display_name = validators.UnicodeString(not_empty=True,
- + max=Group.display_name.property.columns[0].type.length,
- + strip=True)
- + group_name = validators.UnicodeString(not_empty=True,
- + max=Group.group_name.property.columns[0].type.length,
- + strip=True)
-
-
-
-Using the above validators, we also validate the group name in the
-XML-RPC interfaces::
-
- @@ -735,6 +740,7 @@ def create(self, kw):
- try:
- group = Group.by_name(group_name)
- except NoResultFound:
- + GroupFormSchema.fields['group_name'].to_python(group_name)
- group = Group()
- session.add(group)
- activity = Activity(identity.current.user, u'XMLRPC', u'Added', u'Group', u"", kw['display_name'] )
- @@ -813,6 +819,8 @@ def modify(self, group_name, kw):
- raise BX(_(u'Failed to update group %s: Group name already exists: %s' %
- (group.group_name, group_name)))
-
- + GroupFormSchema.fields['group_name'].to_python(group_name)
- +
- user = identity.current.user
- if not group.can_edit(user):
- raise BX(_('You are not an owner of group %s' % group_name))
-
-
-The above validation will raise an ``Invalid`` exception when an
-invalid group name is supplied. Hence, we update the
-``xmlrpcontroller.py`` module to handle the exception and report the
-exception back to the client::
-
- diff --git a/Server/bkr/server/xmlrpccontroller.py b/Server/bkr/server/xmlrpccontroller.py
- index b0794e2..fb5d9bb 100644
- --- a/Server/bkr/server/xmlrpccontroller.py
- +++ b/Server/bkr/server/xmlrpccontroller.py
- @@ -7,6 +7,7 @@
- from turbogears import controllers
- from turbogears.database import session
- from turbogears.identity.exceptions import IdentityFailure, get_identity_errors
- +from formencode.api import Invalid
-
- log = logging.getLogger(__name__)
-
- @@ -65,6 +66,9 @@ def RPC2(self, *args, **kw):
- log.exception('Error handling XML-RPC method')
- # Can't marshal the result
- response = xmlrpclib.dumps(fault)
- + except Invalid, e:
- + session.rollback()
- + response = xmlrpclib.dumps(xmlrpclib.Fault(1, str(e)))
- except:
- session.rollback()
- log.exception('Error handling XML-RPC method')
-
-Since both the XML-RPC and the Web UI were affected by the bug, tests
-were added for both the interfaces. One of the tests to test the
-XML-RPC interface was::
-
- diff --git a/IntegrationTests/src/bkr/inttest/client/test_group_create.py b/IntegrationTests/src/bkr/inttest/client/test_group_create.py
- index dfbed2b..5e60785 100644
- --- a/IntegrationTests/src/bkr/inttest/client/test_group_create.py
- +++ b/IntegrationTests/src/bkr/inttest/client/test_group_create.py
- @@ -1,4 +1,4 @@
- -import unittest
- +import unittest2 as unittest
- from turbogears.database import session
- from bkr.server.model import Activity, Group, User
- from bkr.inttest import data_setup
-
- @@ -47,6 +47,14 @@ def test_group_create(self):
- except ClientError,e:
- self.assert_('Exactly one group name must be specified' in
- e.stderr_output, e.stderr_output)
- + try:
- + out = run_client(['bkr', 'group-create',
- + 'areallylonggroupname'*20])
- + self.fail('Must fail or die')
- + except ClientError,e:
- + max_length = Group.group_name.property.columns[0].type.length
- + self.assertIn('Enter a value less than %r characters long' %
- + max_length, e.stderr_output)
-
-
-A Selenium test was added to test the Web UI for creating and
-modifying groups.
-
-The change to ``model.py`` in this patch means that the database
-schema have to be updated appropriately. Hence, for this patch (and
-for such patches), the appropriate SQL queries to effect the change and
-rollback (in case something goes wrong) should also be included as
-part of the patch. For this patch, the SQL query to effect the change
-was::
-
- ALTER TABLE tg_group MODIFY group_name VARCHAR(255);
-
-The query to rollback the change was::
-
- ALTER TABLE tg_group MODIFY group_name VARCHAR(16);
-
-The entire patch can be seen `here
-<http://git.beaker-project.org/cgit/beaker/commit/?h=develop&id=1b2e8bd80e90733a04948aaa35f68be25fd1b612>`__.
diff --git a/dev/guide/getting-started.rst b/dev/guide/getting-started.rst
deleted file mode 100644
index 7cd8d45..0000000
--- a/dev/guide/getting-started.rst
+++ /dev/null
@@ -1,117 +0,0 @@
-Getting started
-===============
-
-.. highlight:: console
-
-Beaker repository structure
----------------------------
-
-Beaker consists of several different components. The largest and most
-critical are a set of web services that manage an inventory of hardware
-systems distributed across multiple labs and take care of provisioning
-systems appropriately and dispatching jobs to them.
-
-This is the software that is developed in the `main Beaker git
-repository <http://git.beaker-project.org/cgit/beaker/>`_ (click link to
-browse). The bulk of this developer guide focuses on this component.
-
-However, http://git.beaker-project.org plays host to a few other
-components which are also considered part of the wider "Beaker project":
-
-- `beaker-project.org <http://git.beaker-project.org/cgit/beaker-project.org/>`_:
- The source for the project web site (including this developer's
- guide)
-- `beah <http://git.beaker-project.org/cgit/beah/>`_: The test harness
- used to communicate between running tests and the Beaker
- infrastructure. Other test harnesses (such as autotest or STAF) are
- not yet officially supported. Unlike the Beaker web services (which
- are only officially supported on the platforms described below), the
- test harness must run on all operating systems supported for testing.
-- `rhts <http://git.beaker-project.org/cgit/rhts/>`_: The code in this
- repo isn't part of Beaker as such, it's a collection of utilities
- designed to help with writing and running Beaker test cases.
-
-Cloning the main Beaker repo
-----------------------------
-
-Start by cloning `Beaker's git
-repository <http://git.beaker-project.org/cgit/beaker/>`_::
-
- git clone git://git.beaker-project.org/beaker
-
-Update git submodules to keep track of all (recent) JS libraries::
-
- git submodule update --init
-
-For the purposes of development, Beaker should be run on the ``develop``
-branch::
-
- git checkout develop
-
-This branch will become the next Beaker release. If you want to test
-against the latest released version, you can use the ``master`` branch.
-For older releases, use the relevant git tag.
-
-Cloning the other repos is similar to the above, but they all develop
-directly on master (as they don't have a concept of "hot fix" releases
-that only include bug fixes - any release may include a combination of
-both new features and bug fixes)
-
-Running Beaker
---------------
-
-Beaker currently only supports MySQL with InnoDB as the database backend
-(it does use SQL Alchemy internally though, so porting it to an
-alternate backend shouldn't be too difficult). On RHEL and Fedora
-systems, MySQL can easily be installed with::
-
- yum install mysql
-
-For Beaker development, the following settings should be added to
-``/etc/my.cnf`` in the ``[mysqld]`` section before starting the MySQL
-daemon::
-
- default-storage-engine=INNODB
- max_allowed_packet=50M
- character-set-server=utf8
-
-Once these settings are in place, start the database daemon::
-
- service mysqld start
-
-Before running the development server for the first time, you must
-create and populate its database (your working directory should be the
-``Server`` subdirectory of your local clone of the main beaker project)::
-
- mysql -uroot <<"EOF"
- CREATE DATABASE beaker;
- GRANT ALL ON beaker.* TO 'beaker'@'localhost' IDENTIFIED BY 'beaker';
- EOF
- PYTHONPATH=../Common:. python bkr/server/tools/init.py \
- --user=admin \
- --password=adminpassword \
- --email=me@example.com
-
-By default this uses the ``beaker`` database on localhost. This can be
-changed by editing ``dev.cfg`` and updating the above configuration
-commands appropriately.
-
-You can then start a development server using the ``run-server.sh``
-script::
-
- cd Server/
- ./run-server.sh
-
-The Beaker team uses `RHEL
-6 <http://www.redhat.com/products/enterprise-linux/server/>`_ for
-development, testing, and deployment, therefore it is recommended to use
-RHEL 6 when writing your patch. Beaker should also work on Fedora 16 or
-higher, although this configuration is not well tested.
-
-If you want to set up a complete Beaker testing environment (including a
-lab controller) with the ability to provision systems and run jobs,
-refer to :ref:`virtual-fedora`, or the more detailed `installation
-instructions <../../docs/admin-guide/installation.html>`_.
-
-Running Lab Controller processes in a development environment is
-currently not well tested.
diff --git a/dev/guide/index.rst b/dev/guide/index.rst
deleted file mode 100644
index 7f1a2a3..0000000
--- a/dev/guide/index.rst
+++ /dev/null
@@ -1,31 +0,0 @@
-Developer guide
-===============
-
-If you have questions related to Beaker development that aren't
-currently answered in this guide, the two main ways to contact the
-Beaker development team are currently the same as those for getting
-general assistance with using and installing Beaker:
-
-- the `development mailing
- list <https://lists.fedorahosted.org/mailman/listinfo/beaker-devel>`_
-- the #beaker IRC channel on FreeNode (most active during Australian
- east coast business hours, as that's where most of the current
- developers are based, but you may still find a few folks kicking
- around in European and US time zones)
-
-This document focuses on the mechanics of contributing to Beaker. For
-some ideas on possible changes that may be of interest, consult the
-:doc:`technical roadmap <../tech-roadmap>`.
-
-.. toctree::
-
- getting-started
- what-to-work-on
- virtual-fedora/index
- source-walkthrough
- code-guidelines
- ui-guidelines
- cli-guidelines
- writing-a-patch
- example-patch
- development-lifecycle
diff --git a/dev/guide/source-walkthrough.rst b/dev/guide/source-walkthrough.rst
deleted file mode 100644
index f6dd1de..0000000
--- a/dev/guide/source-walkthrough.rst
+++ /dev/null
@@ -1,235 +0,0 @@
-Source code walk-through
-------------------------
-
-Please see the
-`README <http://git.beaker-project.org/cgit/beaker/tree/README>`_ file
-in the root directory of Beaker's source tree for a detailed description
-of its layout.
-
-Lab controller
-~~~~~~~~~~~~~~
-
-The lab controller is the intermediary point of communication between
-the lab machines, and the beaker server. It provides entry points for
-the following processes:
-
-- beaker-proxy
-- beaker-watchdog
-- beaker-transfer
-- beaker-provision
-
-These processes authenticate themselves using the credentials found in
-``/etc/beaker/labcontroller.conf``.
-
-beaker-proxy
-^^^^^^^^^^^^
-
-beaker-proxy is a process that binds to an open unprivileged port on the
-lab controller. It provides an xmlrpc server that more or less forwards
-calls made to it (from lab machines) onto the beaker server.
-
-Here is a simple example of a typical controller from
-``bkr.labcontroller.proxy``:
-
-::
-
- def task_info(self,
- qtask_id):
- """ accepts qualified task_id J:213 RS:1234 R:312 T:1234 etc.. Returns dict with status """
- logger.debug("task_info %s", qtask_id)
- return self.hub.taskactions.task_info(qtask_id)
-
-This is quite straightforward. An xmlrpc call would be made to the the
-lab controller onto port 8000 (the default for beaker-proxy), with the
-method ``task_info`` and the ``qtask id``. The ``task_info()`` method
-then calls and returns ``bkr.server.taskactions.task_info``. The ``hub``
-variable is a ``HubProxy`` class from ``kobo.client``. ``HubProxy`` in
-turn is merely a thin wrapper over ``xmlrpclib.ServerProxy`` that adds
-session based authentication management.
-
-beaker-transfer
-^^^^^^^^^^^^^^^
-
-When provisioning a system in beaker, Beaker transfers various log files
-to the lab controller as a matter of course. Even more log files are
-created when running an actual recipe. By default, these logs are
-uploaded from the test machine to the lab controller.
-
-Using the ``CACHE`` and ``ARCHIVE_*`` variables in
-``labcontroller.conf``, you can specify a remote server where the log
-files can be moved to. Once configured, beaker-transfer is responsible
-for moving these files from the lab controller to the remote server.
-
-beaker-watchdog
-^^^^^^^^^^^^^^^
-
-To ensure that recipes do not run on for longer than what they are
-expected to, Beaker uses a watchdog process. This process keeps track of
-running recipes on all test systems attached to a particular lab
-controller. If a recipe is running for longer than what the server has
-specified it can run for, the watchdog aborts the recipe.
-
-Here is a breakdown of how the process works:
-
-1) Recipe progresses up to the Scheduled stage, and a watchdog is
- created for the recipe.
-2) Recipe goes into ``Waiting`` stage and (amongst others things) a
- reboot command is sent to the lab controller.
-3) System is rebooted and then an RPC is made to the server to start the
- first task, and create a kill time for the watchdog.
-4) For each successive task that is run in the recipe, the harness
- extends the kill time of the watchdog by the expected run time
- specified by the ``TestTime`` value in testinfo.desc.
-5) If a task runs beyond it's kill time, the harness will first try and
- abort the job and continue onto the next test. If the system crashes
- or panics and the harness isn't able to recover then beaker-watchdog
- will abort the recipe (and any remaining tasks). The time between the
- harness watchdog (also known as local watchdog) and beaker-watchdog
- (also known as external watchdog) is ten minutes.
-
-beaker-provision
-^^^^^^^^^^^^^^^^
-
-It is the responsibility of beaker-provision to handle the provisioning
-of a system. Its main duties are creating boot loader images and power
-cycling systems.
-
-Here is a breakdown of how this process works:
-
-1) Beaker server generates and serves a kickstart file.
-2) Beaker server sends a command to beaker-provision with the path to
- the distro tree, kernel options, and a link to the kickstart file. It
- also sends a command to power cycle the system.
-3) From these details, beaker-provision generates the relevant boot
- loader configuration file, and then power cycles the test system.
-4) The system boots and starts its install.
-
-Server
-~~~~~~
-
-The main focus of the beaker server is to maintain a distro and system
-inventory, run tasks against this inventory, and display the results of
-those tasks. Any interaction with this inventory must be via the server.
-For further details of the design of Beaker's services, please see the
-relevant
-`docs <http://beaker-project.org/guide/Administration-Beaker_Architecture.html>`_.
-
-Beaker is developed to run in Red Hat Enterprise Linux 6 (RHEL6).
-Versions previous to 0.7 were designed for RHEL5. Although it may be
-technically possible to run Beaker on other distributions, package
-dependencies and other issues may ensue.
-
-The Beaker server is a web application that is currently a hybrid of
-TurboGears(TG) 1.x and Flask as we migrate to Flask entirely. Here is a
-quick breakdown of the major frameworks/libraries and how Beaker
-server utilizes them.
-
-*TurboGears 1.x*
- TurboGears (TG) is a "front-to-back" web meta-framework. TurboGears 1.x is
- no longer under active development, although the documentation is
- still available on the `TurboGears website
- <http://www.turbogears.org/1.0/docs/>`_. Besides the core modules,
- TG's `widgets` are used for its pre built templates and display
- functionality. Templates are written in `Kid`. A number of
- Beaker's own custom widgets are also built upon TG widgets.
-
-*Kid*
- Provides the templating language for hand written templates, as well as TG
- widgets. Kid is no longer under active development.
-
-*SQLAlchemy*
- An ORM database interface. Used exclusively for all access to Beaker's
- database. Note that Beaker uses some TG database modules, but these are
- thin wrappers over SQLAlchemy.
-
-*Flask/CherryPy 2*
- Provides resource routing, handling of request and response objects.
- `CherryPy 2` is no longer under active development. Starting with
- Beaker 0.15, `Flask` will be used to perform CherryPy's functions
- and hence while Beaker still uses CherryPy, any new code should use
- Flask instead. The existing CherryPy controllers are used as
- fallback handlers upon recieving a 404 error from Flask.
-
-*Javascript libraries/frameworks*
- `MochiKit` is bundled with TG, however JQuery is heavily used
- alongside it. Starting with Beaker 0.15, `Backbone`
- is used to write client side widgets.
-
-*CSS*
- Starting with Beaker 0.15, `Bootstrap` is used for the Web UI front-end.
-
-*Alembic*
- Alembic provides for the creation, management, and invocation of change
- management scripts for a relational database, using SQLAlchemy as the underlying
- engine.
-
-As a result of being built on TG, Beaker is an MVC inspired application.
-Whilst it mostly follows TG conventions, Beaker does sometimes go
-outside of these when it's appropriate (and advantageous) to do so.
-
-Model
-^^^^^
-
-The ``bkr.server.model`` module primarily consists of Object Relational
-Mapped (ORM) classes. Fundamentally, these are user defined python
-classes associated to database tables, the objects of which are mapped
-to rows in the related table.
-
-Controllers
-^^^^^^^^^^^
-
-A controller is called when a HTTP request is made. The URL is
-translated to a particular controller. Starting with Beaker 0.15,
-Flask handles the routing of an URL to the appropriate view method.
-(Previously, CherryPy was used). For example, a call to
-*http://beaker.example.com/tasks/executed* will call the
-``bkr.server.tasks.executed`` method.
-
-Generally speaking, Beaker controllers are grouped into a single module
-for either one of two purposes. Either because the controller provides
-various modifies and accessors for a single ORM class (e.g the
-``bkr.server.system`` module contains various accessor and modifier
-methods for the ``System`` class), or for the purpose of supporting a
-single page view and any associated actions (e.g the
-``bkr.server.preferences`` module contains all of the views and actions
-needed for viewing and updating users preferences).
-
-Sometimes a mix of these two can be found, and this is also fine (i.e
-``bkr.server.tasks`` contains controllers for displaying and searching
-on task details, as well as methods designed to be called remotely to
-provide details of ``Task`` objects).
-
-View
-^^^^
-
-Both Kid templates and TG widgets are used to support the 'View' of MVC.
-Beaker uses TG widgets to provide re-usability of commonly rendered page
-elements. A widget encapsulates the template to be rendered, as well as
-any javascript and CSS files that are needed by that template. Generally
-speaking, creating a widget is preferable to using a controller +
-template due to the re-usability of a widget. However there is no hard
-and fast rule in regards to this.
-
-As well as standard widgets being provided by TG, Beaker also implements
-many of its own widgets in the ``bkr.server.widgets`` module.
-
-Templates are used in one of two ways; by specifying a template in an
-'expose' decorator; by setting the template variable in a widget, and
-then calling that widget's 'display' method. Examples of both will be
-shown in the patch walk-through.
-
-Client
-~~~~~~
-
-The beaker-client package provides shell commands that makes varied
-calls to the server. The format of the calls are
-``bkr <cmd> <options>``, where ``<cmd>`` corresponds to a module in the
-``bkr/client/commands`` directory. The modules of the corresponding code
-is a normalized version of the same name as the command, but with the
-prefix *cmd\_*. For example, ``bkr job-list`` will call the ``run()``
-method of the ``bkr.client.commands.cmd_job_list`` module.
-
-This functionality is provided by the ``kobo.client.ClientCommand``
-class, of which all Beaker commands inherit (indirectly or directly).
-This class also provides the authentication with the Beaker server via
-the same kobo classes as the `lab controller <#lab-controller>`_.
diff --git a/dev/guide/ui-guidelines.rst b/dev/guide/ui-guidelines.rst
deleted file mode 100644
index 3c31c44..0000000
--- a/dev/guide/ui-guidelines.rst
+++ /dev/null
@@ -1,84 +0,0 @@
-
-.. _ui-guidelines:
-
-User interface guidelines
-=========================
-
-.. note::
-
- Most of Beaker's user interface does not currently meet these guidelines,
- due to limitations of the technology stack or historical inconsistencies.
- These guidelines are for new code and describe a state we aim to achieve,
- rather than the current state of the code.
-
-Convey information naturally
-----------------------------
-
-Most of the data in Beaker is viewed much more often than it is edited. Design
-the interface first and foremost to convey the data in the most natural way
-possible; aim for convenience, conciseness, discoverability, and consistency.
-Display simple facts as a phrase or sentence. For a list of homogeneous items,
-use a list. Use a table for tabular data. Position the most important data
-prominently, and less important data unobtrusively (even hidden by default),
-but above all else keep the positions consistent. Emphasize a piece of
-information only if it is unusual or unexpected.
-
-If there is only a small number of possible operations to be performed on the
-data, consider adorning the data directly with unobtrusive buttons to trigger
-these operations. Otherwise, use a single button to trigger a separate
-interface for editing the data (often inside a modal). In the editing
-interface, the data is displayed in the most convenient way for editing it:
-often, a form.
-
-It is tempting to design a form for the data first, and then present a view of
-that data as a form with disabled fields. Avoid this approach; a form is rarely
-the best layout for conveying information, and disabled form fields are
-difficult to read.
-
-Indicate status of server requests
-----------------------------------
-
-In Beaker a button will typically trigger a server request. While the request
-is in progress, the button which triggered it is disabled and a status message
-appears near the trigger indicating that a request is in progress. Use
-a spinner plus a phrase that describes the action being performed
-("Lending...") rather than the mechanics of the request ("Sending server
-request...").
-
-When the server request completes, the trigger returns to its normal state and
-the interface is ready to accept input again. The view is updated with the new
-state reflecting the completed action. If the action does not cause any visible
-changes, a success notification is displayed instead (but this is less
-desirable).
-
-If the server request fails, an error is displayed near the trigger. The error
-text includes any messages returned by the server.
-
-Use Bootstrap components
-------------------------
-
-Bootstrap provides a consistent framework for many common UI components which
-appear in web applications. Use them all to the fullest extent possible.
-
-Use a `button <http://getbootstrap.com/2.3.2/base-css.html#buttons>`_ for an
-action that the user can trigger. Label the button with a verb phrase
-indicating the action it will trigger. Use a hyperlink to link to other
-material or pages. Use a noun phrase as the anchor text.
-
-Group related actions together as a `button group
-<http://getbootstrap.com/2.3.2/components.html#buttonGroups>`_.
-
-Use `alerts <http://getbootstrap.com/2.3.2/components.html#alerts>`_ only when
-the user's attention must be drawn to something in particular: a change that
-has just taken place, a condition out of the ordinary, a failed action.
-
-Capitalize appropriately
-------------------------
-
-Use sentence case for all UI elements, except the following which should be
-labelled in title case:
-
-* buttons
-* tabs
-* menus and menu items
-* column headings
diff --git a/dev/guide/virtual-fedora/index.rst b/dev/guide/virtual-fedora/index.rst
deleted file mode 100644
index 433f8f3..0000000
--- a/dev/guide/virtual-fedora/index.rst
+++ /dev/null
@@ -1,436 +0,0 @@
-.. _virtual-fedora:
-
-Setting up a Beaker test bed
-----------------------------
-
-This guide will help you setup a `Beaker <http://beaker-project.org>`__
-test bed using two virtual machines (VMs). To setup the VMs, we
-will use `libvirt <http://libvirt.org>`__ with `qemu
-<http://qemu.org>`__ driver. The host system is assumed to be running
-an installation of Fedora 20 (although the instructions should also
-work with any other Linux distribution with a suitably recent version
-of libvirt).
-
-.. note::
-
- While there are currently no known major compatibility issues running
- Beaker on Fedora 20, running the Beaker server components on
- Fedora is still considered an *experimental* configuration. Beaker's
- continuous integration system currently only tests compatibility of the
- server components with Red Hat Enterprise Linux 6.
-
-
-Basics of a Beaker test bed
-===========================
-
-Four major components are required to be in place to setup a Beaker
-test bed (also referred to as a Beaker instance):
-
-- *Server*: The Beaker server hosts the web application and the job
- scheduler (and other components such as tasks and the harness
- repository). There is only one server per Beaker instance.
-
-- *Lab controller*: The lab controller is in charge of a lab of test
- systems (described next) and is responsible for receiving and
- acting upon the job requests from the server, setting up the test
- machines (provisioning) and as a proxy between the test systems and
- the server. There can be one or more lab controllers per Beaker
- instance.
-
-- *Test systems*: As their name implies, these are the systems on
- which the tests are actually run. Note that the current
- design of Beaker is such that a test system always starts from
- scratch. At the start of a job, the system is *powered on*, and an
- operating system as specified by the job is installed (In Beaker's
- terminology, this is referred to as *system provisioning*). A test
- system must be associated with a lab controller for Beaker to be
- able to run a job on it.
-
-- *Lab DHCP server*: The test systems should be connected to a network
- with a DHCP server, configured appropriately to fetch the boot
- images from the TFTP server running on the lab controller(s).
-
-For our test bed, we will setup the server and the lab controller on
-the same VM and use a second VM as a test system. The lab DHCP server's
-role is fulfilled by a ``dnsmasq`` instance automatically started by
-``libvirt`` (see `here
-<http://wiki.libvirt.org/page/VirtualNetworking#DNS_.26_DHCP>`__ for
-more) and we shall configure it appropriately to allow network booting
-from the TFTP server running on the lab controller VM.
-
-.. note::
-
- It is worth noting that this guide *exclusively* aims at being an
- easy way to get started with Beaker - both from an user's and a
- developer's perspective. Hence, no attempt has been made to setup
- a secure and robust installation ready to be deployed for any form
- of production use. Refer to the `administration guide
- <../../../docs/admin-guide/>`__ for help on
- setting up a Beaker instance for production use.
-
-In the next sections, we will see how we can setup Beaker. There are
-Bash scripts whereever possible to make the setup easier. However, it
-is encouraged that you read the guide before executing them,
-since that will help you understand the different steps which may be
-useful if you run into an error during the process.
-
-Setting up libvirt
-==================
-
-I assume you have libvirt installed correctly on your *host
-system*. In case you need help, this `guide
-<http://fedoraproject.org/wiki/Getting_started_with_virtualization>`__
-may be of help. We will create a new storage pool to store the images for the two
-VMs using this script. Download the `script
-<scripts/setup_storage.sh>`__ and run it as root user.
-
-Next, we will setup the ``default`` network using this `script
-<scripts/setup_network.sh>`__.
-
-.. note::
-
- This script will *overwrite* your current default network config.
- If you have a customized configuration for your network,
- you should manually add the required configuration described in
- this guide to avoid overwriting the existing configuration.
-
-Download and run the script as the root user.
-
-.. note::
-
- We are using libvirt's system instance (instead of a session
- instance), and hence the scripts are required to be run as root, as
- it allows us to do away with specifying the instance in every script.
-
-There are a number of things in the network config which is worth
-noting such as the DNS and DHCP server configurations and the
-configuration of the TFTP server for PXE booting.
-
-The DNS configuration is as follows::
-
- <dns>
- <host ip='192.168.122.102'>
- <hostname>beaker-server-lc.beaker</hostname>
- </host>
- <host ip='192.168.122.103'>
- <hostname>beaker-test-vm1</hostname>
- </host>
- </dns>
-
-The VM which will act as the server and the lab controller will be
-setup with the hostname ``beaker-server-lc.beaker`` (with an IPv4 address:
-192.168.122.102) and the test VM will have the hostname
-``beaker-test-vm1`` (with an IPv4 address:
-192.168.122.103). Setting up the DNS as above allows the VMs to communicate
-with each other using their hostnames.
-
-.. note::
-
- At this stage, you must also include the entry for your Beaker
- server in your host's :file:`/etc/hosts` file, so that you can
- access the Beaker instance from your host system's browser using the hostname::
-
- 192.168.122.102 beaker-server-lc.beaker
-
- The rest of the guide assumes that this mapping exists.
-
-The tftp and DHCP configuration is as follows::
-
- <tftp root='/var/lib/tftpboot' />
- <dhcp>
- <range start='192.168.122.2' end='192.168.122.254' />
- <host mac='52:54:00:c6:73:4f' name='beaker-server-lc.beaker' ip='192.168.122.102' />
- <host mac='52:54:00:c6:71:8e' name='beaker-test-vm1' ip='192.168.122.103' />
- <bootp file='pxelinux.0' server='192.168.122.102' />
- </dhcp>
-
-The two ``<host>`` elements ensure that the VMs with the hardware
-addresses as above *always* get the hostname and the IPv4 address as
-above. The hardware addresses are set during the setup and hence this
-makes sure that both the VMs get the same IP everytime they are
-started.
-
-As earlier discussed, a test system is provisioned at the start of
-every job. The test system is booted using PXE booting and the element
-``<bootp>`` in the above configuration specifies the filename and the
-PXE server. As you can see, the IPv4 address of the TFTP server is
-that of the server/lab controller VM. The tftp root directory is given by the element
-``<tftp>`` in the above configuration.
-
-Next, we will setup the first VM which will be the server and the lab
-controller.
-
-Setting up Server and Lab controller
-====================================
-
-Installing
-~~~~~~~~~~
-This is to be done on the *host system*. First download this
-`kickstart <scripts/beaker-server-lc.ks>`__ which installs the server and lab
-controller and other miscellaneous packages. Then, from the directory where
-the kickstart file was downloaded, run `this script
-<scripts/create_server_lc_vm.sh>`__ to create a virtual machine and
-start a Fedora 20 installation using the downloaded kickstart file.
-
-You may want to replace the Fedora download location in the Bash script and
-the kickstart by one closer to your geographical location.
-
-Setup server
-~~~~~~~~~~~~
-
-Once the installation has completed, login to the test VM as the root
-user either via SSH from your host or in the VM itself (The root
-password is set to ``fedora``).
-
-We will now setup the Beaker database on the local MariaDB
-server. The following steps need to be completed:
-
-- Setup MariaDB for unicode support
-- Create Beaker database (``beaker``) and give permissions to Beaker's user
-- Initialize Beaker's database
-
-Download and run this `script <scripts/setup_db.sh>`__ to perform the
-above steps. The script will also ask you for the username, password
-and email for creating an ``admin`` account. It is recommended to use
-``admin`` as the username and a password of your choice.
-
-Start the Apache server and the Beaker daemon (scheduler)::
-
- # systemctl start httpd
- # systemctl start beakerd
-
-You may want to confirm that both the services are running (Use
-``# systemctl status httpd`` and ``# systemctl status beakerd`` respectively).
-
-Enable the ``httpd`` and ``beakerd`` services so that they start on system boot::
-
- # systemctl enable httpd beakerd
-
-To be able to access the server web application from your host system,
-add the ``http`` service to the ``default`` zone of ``firewalld`` and
-reload the firewall rules::
-
- # firewall-cmd --permanent --add-service=http
- # firewall-cmd --reload
-
-To test that the web application and the database has been setup
-correctly, visit the URL: ``http://beaker-server-lc.beaker/bkr/`` from
-your host system's browser and try to login as the admin user you created
-earlier. If you are able to login, it means we are good to setup the
-lab controller.
-
-Setup lab controller
-====================
-
-We will now add a lab controller to the Beaker server. Go to
-``http://beaker-server-lc.beaker/bkr/labcontrollers/new`` and add the
-details for the lab controller. The FQDN should be
-``beaker-server-lc.beaker`` (same as the server as earlier explained),
-username should be ``host/localhost.localdomain`` and password as
-``password`` and email as ``root@localhost.localdomain``. These are
-default settings setup during installation in
-:file:`/etc/beaker/labcontroller.conf`. Save the changes.
-
-Enabled and start the TFTP service, which is used to serve netboot files to the
-test VMs::
-
- # systemctl enable tftp.socket
- # systemctl start tftp.socket
-
-Add firewall rules to enable access to the TFTP server (port 69) and
-``beaker-proxy`` running on port 8000::
-
- # firewall-cmd --permanent --add-port=69/udp
- # firewall-cmd --permanent --add-port=8000/tcp
-
-
-Reload the firewall rules so that they are in effect::
-
- # firewall-cmd --reload
-
-Now, start the lab controller daemons::
-
- # systemctl start beaker-proxy beaker-provision beaker-watchdog
-
-To enable the daemons to start on boot::
-
- # systemctl enable beaker-proxy beaker-provision beaker-watchdog
-
-You may want to check if the services are up and running::
-
- # systemctl status beaker-proxy beaker-watchdog beaker-provision
-
-That completes our configuration of the lab controller.
-
-Setup test system
-=================
-
-The script `here <scripts/setup_test_system.sh>`__ will setup the
-second VM. Run this script as the root user on the *host* system.
-It will create a libvirt domain with the name ``beaker-test-vm1``. The
-hardware address of the test VM is setup as ``52:54:00:c6:71:8e`` and it
-will use the ``default`` network.
-
-Now that we have the test system created, add it to Beaker by going to
-``http://beaker-server-lc.beaker/bkr/new`` (you will need to
-be logged in). These are the fields and their values which you must
-enter (or choose):
-
-- System Name: ``beaker-test-vm1``
-- Lab Controller: ``beaker-server-lc.beaker``
-- Type: ``Machine``
-- Mac Address: ``52:54:00:c6:71:8e``
-
-Save the changes. The system should now be accessible at
-``http://beaker-server-lc.beaker/bkr/view/beaker-test-vm1``. Add
-a supported architecture to the system by going to the :guilabel:`Arch(s)` tab of the
-system and add ``x86_64``.
-
-We will now add the power configuration details for the system. This
-is how the system will be powered on during provisioning. Go to the
-:guilabel:`Power Config` tab on the system page (as above) and enter the following
-values against the fields:
-
-- Power Type: ``virsh``
-- Power Address: ``qemu+ssh:192.168.122.1``
-- Power Login: <blank>
-- Power Password: <blank>
-- Power Port/Plug/etc: ``beaker-test-vm1``
-
-Click on :guilabel:`Save Power Changes` to save the configuration.
-
-The default scripts set up two more systems to allow for `multihost testing
-<http://beaker-project.org/docs/user-guide/multihost.html>`__ in the virtual
-Beaker instance. Follow the same steps as above to configure
-them in Beaker, changing only the system name and MAC address:
-
-- System Name: ``beaker-test-vm2``; Mac Address: ``52:54:00:c6:71:8f``
-- System Name: ``beaker-test-vm3``; Mac Address: ``52:54:00:c6:71:90``
-
-If the host system doesn't have the capacity to run all the VMs
-simultaneously, it's reasonable to skip creating or registering the
-additional systems - almost all aspects of Beaker other than multihost
-testing can be exercised with just a single registered system.
-
-As you can see from the ``Power Address`` above, the Beaker lab
-controller will communicate with your host's libvirtd instance
-using ``ssh`` to power on/off the test VM. To make this
-possible, we will have to setup passwordless login from your lab
-controller (that is, the server/labcontroller VM) to your host
-system. First, generate SSH keys on the VM::
-
- # ssh-keygen -t rsa
-
-Then copy it to your host system::
-
- # ssh-copy-id root@<host-ip>
-
-(If you are wondering why do we need to setup passwordless login for
-the root user, that is because the ``beaker-provision`` service which
-handles the test system provisioning runs as the root user and we are
-using the ``system://`` instance of libvirt in this guide).
-
-If everything has completed successfully, you should be able to power
-on the test system from Beaker's web UI. Let's try that. Go the
-:guilabel:`commands` tab of the system at
-``http://beaker-server-lc.beaker/bkr/view/beaker-test-vm1`` and
-click on :guilabel:`Power On System`. After sometime you should see
-the test VM powered on and the PXE boot menu should appear signalling a
-successul PXE boot. Force off the test VM for now.
-
-Setup server to run jobs
-========================
-
-We will now add a few task RPMs to ensure we can run jobs (including those
-with guest recipes) as well as inventory systems and reserve them through
-the scheduler. Use ``wget`` (or an equivalent command) to retrieve the
-latest versions of the standard task RPMs (this is best done on the host
-system rather than the Beaker server VM)::
-
- $ wget -r -np -nc https://beaker-project.org/tasks/
-
-Add the tasks manually via ``http://beaker-server-lc.beaker/bkr/tasks/new``
-or by using the :manpage:`bkr-task-add(1)` command (in the directory where
-the scripts were downloaded, using the admin account configured when
-first installing Beaker)::
-
- $ for f in `ls *.rpm`
- > do
- > bkr task-add --hub=http://beaker-server-lc.beaker/bkr \
- > --username=<USER> --password=<PASSWORD> $f
- > done
-
-Once the tasks have been added, they will be visible at the URL:
-``http://beaker-server-lc.beaker/bkr/tasks/``. At the very least, the
-following tasks should be present:
-
-* ``/distribution/install``
-* ``/distribution/inventory``
-* ``/distribution/reservesys``
-* ``/distribution/virt/install``
-* ``/distribution/virt/start``
-
-To learn more about these tasks, see
-`here <../../../docs/user-guide/beaker-provided-tasks.html>`__.
-
-Next you will have to import distributions into Beaker. These are the
-distributions that you can run your job on. So, depending on your
-needs, these will vary. For example, to import a Fedora 19 mirror, run
-the ``beaker-import`` program on your server VM as follows::
-
- # beaker-import http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/os/
-
-.. note::
-
- It is a good idea to import a mirror closer to your geographical location,
- as the given location will be used to install the operating system when
- provisioning test systems.
-
-Now, go to the URL: ``http://beaker-server-lc.beaker/bkr/distros/`` and
-check if the distro(s) have been imported.
-
-Initialize the harness repos using (on the server VM as the root user)::
-
- # beaker-repo-update
-
-This initializes the harness repositories for each of the distros
-imported above.
-
-Run a job
-=========
-
-Okay, now we are all set to run the first job. The easiest way to do
-this is provision the test system with a distro. Go to the
-:guilabel:`Provision` tab of the system page (test system page as
-earlier), select a distro and click on :guilabel:`Schedule
-provision`. You can see the job status by going to
-``http://beaker-server-lc.beaker/bkr/jobs/`` and also keep track of the
-progress in the test VM itself.
-
-If all goes well, you should see the distro you selected being
-installed. Once the installation is complete, the test system will
-reboot and after sometime, the ``/distribution/install`` task's status should show as
-``Pass`` and the ``/distribution/reservesys`` task should be running,
-which means now you can login to your test system using the default
-root password `beaker` either via SSH or directly in the test VM.
-
-Troubleshooting
-===============
-
-If you see that the test system is not being powered on, or there is
-something unexpected going on, look for any hints in the
-``beaker-provision`` logs (accessible using ``journalctl -u
-beaker-provision``) in the server VM. Log messages from the scheduler
-are accessible via ``journalctl -u beakerd`` and similarly for the other
-services (``beaker-watchdog`` and ``beaker-proxy``). The Beaker web
-application logs are accessible via ``journalctl SYSLOG_IDENTIFIER=beaker-server``.
-
-If you see something is going wrong with the web application, useful
-information may be found in the Apache error logs.
-
-Resources
-=========
-
-- `Beaker user guide <../../../docs/user-guide/index.html>`__
-- `Beaker administrator's guide <../../../docs/admin-guide/>`__
-- `Beaker documentation home <../../../docs/>`__
diff --git a/dev/guide/virtual-fedora/scripts/beaker-server-lc.ks b/dev/guide/virtual-fedora/scripts/beaker-server-lc.ks
deleted file mode 100644
index 7e3f495..0000000
--- a/dev/guide/virtual-fedora/scripts/beaker-server-lc.ks
+++ /dev/null
@@ -1,59 +0,0 @@
-# See http://fedoraproject.org/wiki/Anaconda/Kickstart
-url --url=http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Everything/x86_64/os/
-repo --name=updates
-repo --name=beaker-server --baseurl=http://beaker-project.org/yum/server/Fedora20
-
-
-auth --useshadow --enablemd5
-firstboot --disable
-clearpart --all --initlabel
-
-# auto partition
-autopart
-
-bootloader --location=mbr
-keyboard us
-lang en_US
-timezone America/New_York
-network --hostname=beaker-server-lc.beaker
-install
-shutdown
-
-# root pw: fedora
-rootpw --iscrypted $1$I1lI.tL5$qOMpgkPrJIxc2vc29oHh./
-
-# till we have a policy for beaker, disable.
-selinux --disabled
-
-%packages
-beaker-server
-beaker-lab-controller
-
-# these are not tracked by beaker dependencies, so we have to manually
-# install these
-autofs
-#MariaDB
-mariadb-server
-MySQL-python
-tftp-server
-mod_ssl
-
-# we will need to power on the test systems from the LC, so we need
-# virsh
-libvirt-client
-
-#utilities
-wget
-
-%end
-
-%post
-
-set -x -v
-exec 1>/root/ks-post.log 2>&1
-
-systemctl enable mysqld
-systemctl enable xinetd
-systemctl enable tftp
-
-%end
diff --git a/dev/guide/virtual-fedora/scripts/create_server_lc_vm.sh b/dev/guide/virtual-fedora/scripts/create_server_lc_vm.sh
deleted file mode 100755
index fb9aa84..0000000
--- a/dev/guide/virtual-fedora/scripts/create_server_lc_vm.sh
+++ /dev/null
@@ -1,14 +0,0 @@
-#!/bin/bash
-
-# root
-if (( EUID != 0 )); then
- echo "You must be root to do this." 1>&2
- exit 100
-fi
-
-virt-install \
- --location=http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/os/\
- --initrd-inject=beaker-server-lc.ks --extra-args=ks=file:/beaker-server-lc.ks \
- --name=beaker-server-lc --network=network=default --mac=52:54:00:c6:73:4f \
- --ram=2048 --vcpus=2 \
- --disk path=/beaker_images/server-lc.img
diff --git a/dev/guide/virtual-fedora/scripts/setup_db.sh b/dev/guide/virtual-fedora/scripts/setup_db.sh
deleted file mode 100755
index 1ac10d2..0000000
--- a/dev/guide/virtual-fedora/scripts/setup_db.sh
+++ /dev/null
@@ -1,51 +0,0 @@
-#!/bin/bash
-# This script will setup MariaDB, create the beaker DB
-# and populate it's tables
-# Create an admin user for Beaker
-
-set -e
-
-# root
-if (( EUID != 0 )); then
- echo "You must be root to do this." 1>&2
- exit 100
-fi
-
-#Let's apply some useful settings to the MariaDB server.
-cp /etc/my.cnf /etc/my.cnf-orig
-cat /etc/my.cnf-orig | awk '
- {print $0};
- /\[mysqld\]/ {
- print "character-set-server=utf8";
- }' > /etc/my.cnf
-
-systemctl start mariadb
-systemctl enable mariadb
-
-# setup Beaker DB
-echo "CREATE DATABASE beaker;" | mysql
-echo "GRANT ALL ON beaker.* TO 'beaker'@'localhost' IDENTIFIED BY 'beaker';" | mysql
-
-# initialize Beaker DB tables
-echo -n "Please enter a login name for the Beaker admin account: "
-read admin
-echo -n "Please enter an email address for $admin: "
-read email
-password="dummy"
-stty -echo
-trap "stty echo; exit" INT TERM EXIT
-while [ "$password" != "$password_again" ]; do
- echo -n "Please enter a passowrd for $admin: "
- read password
- echo
- echo -n "Please enter the password again: "
- read password_again
- echo
- if [ "$password" != "$password_again" ]; then
- echo "Passwords don't match, try again"
- echo
- fi
-done
-stty echo
-trap - INT TERM EXIT
-su -s /bin/sh apache -c "beaker-init -u \"$admin\" -p \"$password\" -e \"$email\""
diff --git a/dev/guide/virtual-fedora/scripts/setup_network.sh b/dev/guide/virtual-fedora/scripts/setup_network.sh
deleted file mode 100755
index ccbadfb..0000000
--- a/dev/guide/virtual-fedora/scripts/setup_network.sh
+++ /dev/null
@@ -1,59 +0,0 @@
-#!/bin/bash
-
-# Abort if any step fails
-set -e
-
-# root
-if (( EUID != 0 )); then
- echo "You must be root to do this." 1>&2
- exit 100
-fi
-
-# This script sets up the default network
-function setup_network()
-{
-
-virsh net-destroy default || true
-virsh net-undefine default || true
-
-( cat <<__EOF__
- <network>
- <name>default</name>
- <forward mode='nat'/>
- <bridge name='virbr0' stp='on' delay='0' />
- <mac address='52:54:00:6B:11:87'/>
- <dns>
- <host ip='192.168.122.102'>
- <hostname>beaker-server-lc.beaker</hostname>
- </host>
- <host ip='192.168.122.103'>
- <hostname>beaker-test-vm1</hostname>
- </host>
- <host ip='192.168.122.104'>
- <hostname>beaker-test-vm2</hostname>
- </host>
- <host ip='192.168.122.105'>
- <hostname>beaker-test-vm3</hostname>
- </host>
- </dns>
- <ip address='192.168.122.1' netmask='255.255.255.0'>
- <tftp root='/var/lib/tftpboot' />
- <dhcp>
- <range start='192.168.122.2' end='192.168.122.254' />
- <host mac='52:54:00:c6:73:4f' name='beaker-server-lc.beaker' ip='192.168.122.102' />
- <host mac='52:54:00:c6:71:8e' name='beaker-test-vm1' ip='192.168.122.103' />
- <host mac='52:54:00:c6:71:8f' name='beaker-test-vm2' ip='192.168.122.104' />
- <host mac='52:54:00:c6:71:90' name='beaker-test-vm3' ip='192.168.122.105' />
- <bootp file='pxelinux.0' server='192.168.122.102' />
- </dhcp>
- </ip>
-</network>
-
-__EOF__
-) | virsh net-define /dev/stdin
-
-virsh net-start default
-virsh net-autostart default
-}
-
-setup_network
diff --git a/dev/guide/virtual-fedora/scripts/setup_storage.sh b/dev/guide/virtual-fedora/scripts/setup_storage.sh
deleted file mode 100755
index 496fa56..0000000
--- a/dev/guide/virtual-fedora/scripts/setup_storage.sh
+++ /dev/null
@@ -1,110 +0,0 @@
-#!/bin/bash
-
-# Abort if any step fails
-set -e
-
-# root
-if (( EUID != 0 )); then
- echo "You must be root to do this." 1>&2
- exit 100
-fi
-
-
-# This script creates a storage pool with the name
-# beaker-images and then creates two volumes in this pool
-
-# define a persistent storage pool
-function def_storage_pool()
-{
-
-mkdir -p /beaker_images
-
-( cat <<__EOF__
- <pool type="dir">
- <name>beaker_images</name>
- <target>
- <path>/beaker_images</path>
- </target>
- </pool>
-__EOF__
-) | virsh pool-define /dev/stdin
-
-# start and setup for autostart
-virsh pool-start beaker_images
-virsh pool-autostart beaker_images
-}
-
-# define the storage volume for the server/lc
-# 20 GiB
-function def_server_lc_storage()
-{
-( cat <<__EOF__
-<volume>
- <name>server-lc.img</name>
- <source>
- </source>
- <capacity>21474836480</capacity>
- <allocation>8589934592</allocation>
- <target>
- <path>/beaker_images/server-lc.img</path>
- <format type='raw'/>
- </target>
-</volume>
-__EOF__
-) | virsh vol-create beaker_images /dev/stdin
-}
-
-# define the storage volume for a beaker test VM
-# 10 GiB
-function def_test_systems_storage()
-{
-( cat <<__EOF__
-<volume>
- <name>test-system1.img</name>
- <source>
- </source>
- <capacity>10737418240</capacity>
- <allocation>10737418240</allocation>
- <target>
- <path>/beaker_images/test-system1.img</path>
- <format type='raw'/>
- </target>
-</volume>
-__EOF__
-) | virsh vol-create beaker_images /dev/stdin
-( cat <<__EOF__
-<volume>
- <name>test-system2.img</name>
- <source>
- </source>
- <capacity>10737418240</capacity>
- <allocation>10737418240</allocation>
- <target>
- <path>/beaker_images/test-system2.img</path>
- <format type='raw'/>
- </target>
-</volume>
-__EOF__
-) | virsh vol-create beaker_images /dev/stdin
-( cat <<__EOF__
-<volume>
- <name>test-system3.img</name>
- <source>
- </source>
- <capacity>10737418240</capacity>
- <allocation>10737418240</allocation>
- <target>
- <path>/beaker_images/test-system3.img</path>
- <format type='raw'/>
- </target>
-</volume>
-__EOF__
-) | virsh vol-create beaker_images /dev/stdin
-}
-
-#define, start and mark the pool for autostart
-def_storage_pool
-
-# define the storage volumes
-def_server_lc_storage
-def_test_systems_storage
diff --git a/dev/guide/virtual-fedora/scripts/setup_test_system.sh b/dev/guide/virtual-fedora/scripts/setup_test_system.sh
deleted file mode 100755
index 0822a32..0000000
--- a/dev/guide/virtual-fedora/scripts/setup_test_system.sh
+++ /dev/null
@@ -1,123 +0,0 @@
-#!/bin/bash
-# This script sets up the test system
-
-# Abort if any step fails
-set -e
-if (( EUID != 0 )); then
- echo "You must be root to do this." 1>&2
- exit 100
-fi
-
-
-function setup_test_systems()
-{
-
-virsh destroy beaker-test-vm1 || true
-virsh undefine beaker-test-vm1 || true
-virsh destroy beaker-test-vm2 || true
-virsh undefine beaker-test-vm2 || true
-virsh destroy beaker-test-vm3 || true
-virsh undefine beaker-test-vm3 || true
-
-(cat <<__EOF__
-<domain type='kvm'>
- <name>beaker-test-vm1</name>
- <memory unit='KiB'>2097152</memory>
- <vcpu>1</vcpu>
- <os>
- <type arch='x86_64'>hvm</type>
- <boot dev='network'/>
- <boot dev='hd'/>
- <bootmenu enable='no'/>
- </os>
- <clock offset='utc'/>
- <on_poweroff>destroy</on_poweroff>
- <on_reboot>restart</on_reboot>
- <on_crash>restart</on_crash>
- <devices>
- <disk type='file' device='disk'>
- <driver name='qemu' type='raw'/>
- <source file='/beaker_images/test-system1.img'/>
- <target dev='vda' bus='virtio'/>
- </disk>
- <interface type='network'>
- <mac address='52:54:00:c6:71:8e'/>
- <source network='default'/>
- <model type='virtio'/>
- </interface>
- <memballoon model='virtio'/>
- <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
- </devices>
-</domain>
-__EOF__
-) | virsh define /dev/stdin
-
-(cat <<__EOF__
-<domain type='kvm'>
- <name>beaker-test-vm2</name>
- <memory unit='KiB'>2097152</memory>
- <vcpu>1</vcpu>
- <os>
- <type arch='x86_64'>hvm</type>
- <boot dev='network'/>
- <boot dev='hd'/>
- <bootmenu enable='no'/>
- </os>
- <clock offset='utc'/>
- <on_poweroff>destroy</on_poweroff>
- <on_reboot>restart</on_reboot>
- <on_crash>restart</on_crash>
- <devices>
- <disk type='file' device='disk'>
- <driver name='qemu' type='raw'/>
- <source file='/beaker_images/test-system2.img'/>
- <target dev='vda' bus='virtio'/>
- </disk>
- <interface type='network'>
- <mac address='52:54:00:c6:71:8f'/>
- <source network='default'/>
- <model type='virtio'/>
- </interface>
- <memballoon model='virtio'/>
- <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
- </devices>
-</domain>
-__EOF__
-) | virsh define /dev/stdin
-
-(cat <<__EOF__
-<domain type='kvm'>
- <name>beaker-test-vm3</name>
- <memory unit='KiB'>2097152</memory>
- <vcpu>1</vcpu>
- <os>
- <type arch='x86_64'>hvm</type>
- <boot dev='network'/>
- <boot dev='hd'/>
- <bootmenu enable='no'/>
- </os>
- <clock offset='utc'/>
- <on_poweroff>destroy</on_poweroff>
- <on_reboot>restart</on_reboot>
- <on_crash>restart</on_crash>
- <devices>
- <disk type='file' device='disk'>
- <driver name='qemu' type='raw'/>
- <source file='/beaker_images/test-system3.img'/>
- <target dev='vda' bus='virtio'/>
- </disk>
- <interface type='network'>
- <mac address='52:54:00:c6:71:90'/>
- <source network='default'/>
- <model type='virtio'/>
- </interface>
- <memballoon model='virtio'/>
- <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
- </devices>
-</domain>
-__EOF__
-) | virsh define /dev/stdin
-
-}
-
-setup_test_systems
diff --git a/dev/guide/what-to-work-on.rst b/dev/guide/what-to-work-on.rst
deleted file mode 100644
index 380cf07..0000000
--- a/dev/guide/what-to-work-on.rst
+++ /dev/null
@@ -1,24 +0,0 @@
-What can I work on?
-===================
-
-For meatier projects, Beaker's :doc:`technical roadmap <../tech-roadmap>` is
-the best place to look. It has a curated list of things we want to achieve with
-Beaker, ordered from more immediate goals to longer term ambitions or ideas.
-The Beaker community is also never short on ideas for improving Beaker, and
-there is a long list of miscellaneous `RFEs in Bugzilla
-<https://bugzilla.redhat.com/buglist.cgi?product=Beaker&bug_status=__open__&keywords=FutureFeature>`__.
-
-You can also browse the list of `open bugs in Bugzilla
-<https://bugzilla.redhat.com/buglist.cgi?product=Beaker&bug_status=__open__&keywords=FutureFeature%2CDocumentation&keywords_type=nowords>`__.
-Some of these bugs are caused by assumptions deeply ingrained in Beaker, or
-flaws inherent in Beaker's architecture, making them difficult to fix. But some
-of them are straightforward and should be simple to fix. You can find the
-simpler bugs by looking for the `EasyFix keyword
-<https://bugzilla.redhat.com/buglist.cgi?product=Beaker&bug_status=__open__&keywords=EasyFix>`__
-or an `Original Estimate less than
-5 <https://bugzilla.redhat.com/buglist.cgi?product=Beaker&bug_status=__open__&keywords=FutureFeature%2CDocumentation&keywords_type=nowords&f1=estimated_time&o1=greaterthan&v1=0&f2=estimated_time&o2=lessthan&v2=5>`_.
-
-If you feel like writing documentation, Beaker can always use help in that
-regard. There are still plenty of areas in Beaker which are under-documented.
-You can find some specific ideas by looking for `documentation bugs in Bugzilla
-<https://bugzilla.redhat.com/buglist.cgi?product=Beaker&bug_status=__open__&keywords=Documentation>`__.
diff --git a/dev/guide/writing-a-patch.rst b/dev/guide/writing-a-patch.rst
deleted file mode 100644
index 9716586..0000000
--- a/dev/guide/writing-a-patch.rst
+++ /dev/null
@@ -1,258 +0,0 @@
-Writing a patch
-===============
-
-.. highlight:: console
-
-Create a local working branch
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Start by creating a local git branch where you will commit your work::
-
- git checkout origin/develop -b myfeature
-
-This will create a local git branch called ``myfeature`` that is associated
-with the upstream ``develop`` branch for easy rebasing.
-
-For new features and any invasive bug fixes (e.g. those requiring database
-changes), the working branch should be based on ``origin/develop`` as shown.
-
-For bug fixes that don't require invasive changes, then the working branch
-should be based on the latest release branch. For example, if the latest
-release shown on the `release download page
-<http://beaker-project.org/releases/>`__ is Beaker 0.15, then local branches
-to work on bug fixes should be created with a command like::
-
- git checkout origin/release-0.15 -b bz123456_fix_this_bug
-
-Including the bug number in the branch name isn't required (since the branch
-name is never published to anyone else), but it's a useful reference point
-when working on multiple patches in parallel.
-
-
-Testing your patch
-~~~~~~~~~~~~~~~~~~
-
-Beaker has a large and thorough suite of integration tests, including
-many `Selenium/WebDriver <http://code.google.com/p/selenium/>`_ browser
-tests. You should test your patch by running the test suite either
-locally or in Beaker, or both.
-
-In order to run the test suite locally, you must create two additional
-test databases in your local MySQL instance::
-
- mysql -uroot <<"EOF"
- CREATE DATABASE beaker_test;
- GRANT ALL ON beaker_test.* TO 'beaker'@'localhost' IDENTIFIED BY 'beaker';
- EOF
-
- mysql -uroot <<"EOF"
- CREATE DATABASE beaker_migration_test;
- GRANT ALL ON beaker_migration_test.* TO 'beaker'@'localhost' IDENTIFIED BY 'beaker';
- EOF
-
-While working on your patch, you would run the unit test for your new
-feature/fix::
-
- cd IntegrationTests/
- ./run-tests.sh -sv bkr.inttest.path_to_my_new_test
-
-Once the new or updated test is passing, you should also run the whole
-suite to check for unintended side effects::
-
- ./run-tests.sh
-
-The ``run-tests.sh`` script is a thin wrapper around
-`nosetests <http://readthedocs.org/docs/nose/>`_ which sets up
-``PYTHONPATH`` for running from a git checkout.
-
-Once you've verified the patch passes the test suite, commit it to your
-local branch::
-
- git commit
-
-You can also run the Beaker test suite in Beaker (assuming you have
-access to a working Beaker instance) using the
-``/distribution/beaker/dogfood`` task. If your Beaker instance doesn't
-already have a copy of this task, you can build it from Beaker's source
-under the ``Tasks`` subdirectory. You can base your job on this `sample
-dogfood job XML <../../sample-dogfood-job.xml>`_.
-
-You can use ``Misc/rpmbuild.sh`` to build Beaker RPMs for testing::
-
- Misc/rpmbuild.sh -bb
-
-or if you have Mock or Koji suitably configured, you can generate an
-SRPM and build from that::
-
- Misc/rpmbuild.sh -bs
-
-The ``Misc/rpmbuild.sh`` script will build from the HEAD commit
-in git, so make sure you have committed your changes to your local
-branch.
-
-If the patch changes an existing feature or adds a new one,
-then ideally the relevant documentation should be updated. Also note that
-linking the documented feature to the release notes, and/or using the
-'versionchanged/versionadded' directive where appropriate is encouraged.
-
-Submitting your patch
-~~~~~~~~~~~~~~~~~~~~~
-
-The Beaker project uses the `Gerrit <http://code.google.com/p/gerrit/>`_
-code review tool to manage patches. All patches are reviewed on Beaker's
-Gerrit installation before being merged:
-
- `http://gerrit.beaker-project.org/ <http://gerrit.beaker-project.org>`_
-
-New users can sign in using any OpenID account (preferably your `Fedora
-OpenID <http://fedoraproject.org/wiki/OpenID>`_; avoid using Google
-Accounts). Be sure to configure your e-mail addresses and SSH keys in
-Gerrit after creating your account. Your SSH key is needed to
-authenticate you when pushing patches using git. The e-mail address in
-your git commits must also match one of the e-mail addresses you have
-registered in Gerrit.
-
-For convenience you can add the Gerrit server as a remote to your
-``.git/config``::
-
- [remote "gerrit"]
- url = git+ssh://gerrit.beaker-project.org:29418/beaker
-
-Once you're happy with the change and the test you have written for it,
-push your local branch to Gerrit for review::
-
- git push gerrit myfeature:refs/for/develop
-
-The destination branch in Gerrit should match the branch used as a basis for
-the patch. For a bug fix targeting Beaker 0.15, the appropriate command would
-look like::
-
- git push gerrit bz123456_fix_this_bug:refs/for/release-0.15
-
-A new "change" in Gerrit will be created from your commit. Beaker
-developers can then review and merge it as appropriate. See the `Gerrit
-documentation <http://gerrit.googlecode.com/svn/documentation/2.2.1/index.html>`_
-for more info.
-
-If your patch fixes a bug, be sure to include a reference to the
-Bugzilla number as a footer line like "Bug: 123456" in the commit
-message (`example <http://git.beaker-project.org/c/b/c9bd4bf>`_).
-
-To update the patch on an existing change, you can use
-``git commit --amend``. You must ensure that the correct Change-Id
-footer appears in your amended commit message. Refer to the Gerrit
-`Change-Id <http://gerrit.googlecode.com/svn/documentation/2.2.1/user-changeid.html>`_
-documentation for more details.
-
-To avoid forgetting the Change-Id footer and accidentally creating a new
-review instead of updating an existing one, it's useful to install this
-hook which automatically adds an appropriate "Change-Id" entry to the
-commit message when a patch is first committed locally::
-
- scp -p -P 29418 gerrit.beaker-project.org:hooks/commit-msg .git/hooks/
-
-
-Reviewing a patch
-~~~~~~~~~~~~~~~~~
-
-For a change to make it through review and be merged into the
-development branch for the next Beaker release, it needs to first be
-marked in Gerrit as "+1 Verified" and have a "+2 Looks good to me,
-approved" code review (only the core Beaker developers can grant the
-latter).
-
-The "+1 Verified" marker indicates one of the following:
-
-- If it's a bug fix that is reproduceable and testable, the new test
- case has been verified to fail before the fix, and pass after the
- fix.
-- If it's a bug fix that is not amenable to an automated test, the
- patch has been verified to fix the bug through some other means (such
- as trying it out manually).
-- If it's a new feature, the feature has been verified to work as
- described.
-- If it's a code change, the test suite has been verified to pass in
- full.
-- If it's a docs change, the docs have been verified to build correctly
- and look right.
-- On some rare occasions (for example, fixing a typo in a comment or
- README), it may simply indicate that the patch has been determined
- not to run a risk of breaking the application or documentation.
-
-The "+2 Approved" code review marker should only be granted when all the
-following criteria are met:
-
-- The patch is targetting the right branch (develop for new features and
- invasive bug fixes, latest release branch for non-invasive bug fixes)
-- All significant review comments have been addressed, with the aim of
- ensuring the Beaker code remains maintainable rather than
- degenerating over time.
-- Whenever practical, automated tests have been added to ensure the bug
- fix or new feature works as expected.
-- The code is commented appropriately (for example, explanations or
- issue tracker references are included for any obscure workarounds).
-- The documentation (including docstrings) has been updated
- appropriately
-- A release note has been added as described in the `What's New
- source <http://git.beaker-project.org/cgit/beaker/tree/documentation/whats-new/index.rst?h=develop>`_
- for new features, bug fixes that may break existing workarounds, and
- any changes that require manual steps from system administrators when
- upgrading an existing installation.
-- The commit message is correctly formatted with a short summary line
- and any additional continuation lines separated from the summary by a
- blank line.
-- For changes driven by a Bugzilla entry, the correct "Bug: NNNNNN"
- reference is present in the commit message (as described above in
- "Submitting your patch").
-- For functional and testing changes (that is, changes affecting code, not
- just documentation), another core developer has already granted
- "+1 Looks good to me, but someone else must approve" based on the
- above criteria (this criterion may occasionally be waived based on
- core developer availability).
-
-Reviewers should also be looking for "missing updates": changes which
-*should* have been made, but are not part of the current patch. For
-example, if a new attribute is added for Jobs, then the Job detail page
-should probably be updated to display that attribute as well. Another
-example would be that if a patch changes the repo layout, then the
-description of that layout in the README file should also be updated.
-
-There's no simple guideline to help identify "what's missing" in cases
-that aren't automatically detected through failing tests: it's something
-that can only come from experience with Beaker and its code. To minimise
-such cases, it is often desirable to add a test case that ensures the
-two components are kept in sync, rather than relying on developers to
-remember to update both places (assuming the duplication can't be
-eliminated entirely by changing the implementation). That way, the
-missing updates should be picked up automatically as a failure in the
-test suite, rather than requiring the patch creator or reviewer to
-notice that additional changes are needed.
-
-
-Exceptions to the review process
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Core developers are permitted to bypass the review process by setting the
-review on their own patches in at least the following circumstances:
-
-- when a previously approved patch needs to be rebased to get Gerrit to merge
- it, but no actual changes were needed as part of the rebase (Gerrit is
- configured to rebase automatically, but the web UI sometimes gets confused
- and hides the submit button even though the rebase would work automatically)
-- when minor fixes have been made to a previously approved documentation
- patch (documentation patch reviews are mainly aimed at overall structure
- and picking up omissions and technical errors. Fixing a typo or grammar
- error doesn't require restarting the entire review process)
-- updating the git submodules for the beaker-project.org documentation (this
- may be pushed directly to git, bypassing Gerrit entirely)
-- design proposal updates (design proposals should generally be discussed on
- the development mailing list rather than in a Gerrit review, although the
- latter can be useful for line-by-line commenting on specific details)
-- technical road map updates (the overall technical road map is only updated
- by, or at the direction of, the Beaker Development Lead, rather than using
- the regular change review process)
-- any changes to the beaker-administrivia repo (these scripts are just used
- to help with issue management and status tracking, and don't directly
- impact the actual functional code, tests or documentation)
-
-As other exceptional cases are identified, they will also be noted here.
diff --git a/dev/index.rst b/dev/index.rst
deleted file mode 100644
index 765df70..0000000
--- a/dev/index.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-Beaker development
-==================
-
-This documentation covers various aspects of Beaker's
-development process, including details of previous and current major design
-proposals.
-
-.. toctree::
- :maxdepth: 1
-
- guide/index
- proposals/index
- tech-roadmap
- related-projects
- bpo
-
-You can also view the `draft documentation <../docs-develop/>`_ for the next
-Beaker release, built from the develop branch of Beaker's git.
diff --git a/dev/proposals/README b/dev/proposals/README
deleted file mode 100644
index 4a42607..0000000
--- a/dev/proposals/README
+++ /dev/null
@@ -1,2 +0,0 @@
-Major design proposals should be written up as articles in this directory
-and added to the Design Proposals TOC in dev/index.rst
diff --git a/dev/proposals/access-policies-for-systems.rst b/dev/proposals/access-policies-for-systems.rst
deleted file mode 100644
index 6a5a161..0000000
--- a/dev/proposals/access-policies-for-systems.rst
+++ /dev/null
@@ -1,164 +0,0 @@
-.. _proposal-access-policies:
-
-Access Policies for Systems
-===========================
-
-:Author: Dan Callaghan, Nick Coghlan
-:Status: Deferred
-:Initial Release: `0.15 <http://beaker-project.org/docs/whats-new/release-0.15.html>`__
-:Target Final Release: TBD
-
-
-Abstract
---------
-
-This proposal replaces the existing mechanisms for controlling access to
-systems with a single unified "access policy". It also provides a way to
-optionally apply the same access policy consistently across many systems.
-
-
-Implementation deferral
------------------------
-
-The "predefined access policy" component of this proposal is not yet
-implemented. Since the per-system policies can be configured remotely,
-implementation of the remainder of the design is currently deferred
-indefinitely.
-
-
-Access policies
----------------
-
-Beaker's current system management design offers system owners little
-flexibility in providing access to their systems. This proposal enhances
-the system management capability by allowing system owners to grant
-varying levels of access to different users and groups.
-
-An access policy is a list of rules which grant any of the following
-permissions to any number of users or groups:
-
-* edit this access policy (``edit-policy``)
-* edit system details (``edit-system``)
-* loan system to anyone (``loan-any``)
-* loan system to self (``loan-self``)
-* issue power and provisioning commands (``control-system``)
-* reserve system (either through the scheduler when set to Automated, or via
- the web UI or bkr client when set to Manual) (``reserve``)
-
-Access policies replace the existing mechanisms for controlling access to
-systems: the Shared flag and group membership.
-
-The system owner always has complete control over their system, which means
-that they implicitly have all of the above permissions. The system owner's
-permissions will not appear explicitly in the access policy.
-
-
-Predefined access policies
---------------------------
-
-By default, new systems have no access policy. That means no other Beaker users
-have permission to use the system.
-
-A system owner can define a "custom access policy" for their system. This
-policy is specific to a single system. The system owner can always modify the
-custom policy. If the policy grants the ``edit-policy`` permission to other
-users, then they can edit the custom policy as well.
-
-Alternatively, a system owner can apply an existing "predefined access policy"
-to their system, or create a new predefined policy. Predefined policies have
-a descriptive name, such as "Company-wide shared systems" or "QE team systems".
-Once a predefined policy has been created, any system owner can apply it to
-their system.
-
-When a predefined policy is first created, its creator is granted
-``edit-policy`` permission on it automatically. They can then grant
-``edit-policy`` permission to other users or groups to share administrative
-responsibility if desired.
-
-Note that a system owner does not automatically gain access to edit
-a predefined policy when they apply it to their system. In applying
-a predefined policy which they do not themselves control, a system owner is
-effectively delegating management of the permissions for their system to the
-user(s) responsible for the predefined policy.
-
-
-Proposed user interface
------------------------
-
-Web UI
-~~~~~~
-
-The existing :guilabel:`Shared` check box and :guilabel:`Groups` tab on the
-system page will be removed.
-
-A new tab on the system page, :guilabel:`Access Policy`, will show the system's
-current access policy. It will also display the effective permissions for the
-current user, to make it easier for users to interpret the policy and to
-determine "do I have access to this system?".
-
-Access policies are displayed as a matrix of check boxes, with one row for each
-user or group in the policy, and one column for each permission. Groups are
-prefixed with :guilabel:`Group:` and users with :guilabel:`User:` to
-distinguish them. A special row, labelled :guilabel:`Everyone`, always appears
-as the first row: this defines permissions for all Beaker users.
-
-For the system owner, this tab will also have an interface to select whether to
-apply a custom policy, apply an existing predefined policy, or create a new
-predefined policy. If the owner has applied a custom policy or a predefined
-policy which they have permission to edit, they can click a link labelled
-:guilabel:`Edit` to go to the Edit Access Policy page.
-
-On the Edit Access Policy page, users can edit the name of the policy and its
-permissions. Permissions are displayed in a matrix, as on the system page, with
-the addition of :guilabel:`Add` and :guilabel:`Remove` buttons to add and
-remove rows from the matrix.
-
-Command-line client
-~~~~~~~~~~~~~~~~~~~
-
-Apply a predefined access policy to a system::
-
- bkr system-set-policy --policy="dcallagh's systems" mybox.example.com
-
-Grant and revoke permissions in a predefined policy::
-
- bkr policy-grant --policy="dcallagh's systems" \
- --permission=edit-system --user=dcallagh
-
- bkr policy-grant --policy="dcallagh's systems" \
- --permission=loan-self --group=beakerdevs
-
- bkr policy-grant --policy="dcallagh's systems" \
- --permission=reserve --everyone
-
- bkr policy-revoke --policy="dcallagh's systems" \
- --permission=reserve --everyone
-
-
-Upgrading existing Beaker installations
----------------------------------------
-
-As part of the upgrade, a migration step will map each system's existing Shared
-flag and group memberships to a new access policy. The mapping will be
-performed as follows:
-
-* If the Shared flag is set and the system has no groups, the ``reserve``
- permission will be granted to everyone.
-
-* For each group which has admin access to the system, all permissions will be
- granted to the group.
-
-* For each group which does not have admin access, if the Shared flag is set,
- the ``reserve`` permission will be granted to the group.
-
-In addition, the ``control-system`` permission will be granted to everyone for
-all existing systems. This matches Beaker's current behaviour, which permits
-any user to power any system. This default will not be applied to new systems.
-
-
-Deferred features
------------------
-
-In future, it would be possible to add an extra permission for system
-visibility. This would replace the existing Secret flag with a finer-grained
-mechanism for controlling who can see systems which are covered by NDAs.
diff --git a/dev/proposals/beaker-usage-report-emails.rst b/dev/proposals/beaker-usage-report-emails.rst
deleted file mode 100644
index 9b3e77d..0000000
--- a/dev/proposals/beaker-usage-report-emails.rst
+++ /dev/null
@@ -1,123 +0,0 @@
-.. _proposal-beaker-usage-report-emails:
-
-Beaker Usage Report Emails
-==========================
-
-:Author: Nick Coghlan, Matt Jia
-:Status: Implemented
-:Release: `0.18 <https://beaker-project.org/docs/whats-new/release-0.18.html#usage-reminder-emails>`__
-
-
-Abstract
---------
-
-Currently, the Beaker usage reminder system sends users a separate email
-for every system they have reserved. This can get very spammy
-for heavy users, and may make instance admins reluctant to
-enable the feature.
-
-This proposal redesigns the current Beaker usage reminder system, allowing
-it to be user based.
-
-(See also: :issue:`994325`)
-
-
-Beaker usage report emails
---------------------------
-
-The existing usage alert email mechanism will be redesigned to send at
-most one email per user, per day. An alert email will be the sent to users
-under the following conditions:
-
-* Expiring Reservations
-
- * they have a recipe running /distribution/reservesys or in "Reserved"
- status and the associated watchdog timer will expire within 24 hours.
-
-* Reservations for In Demand Systems
-
- * they have had a system reserved for at least 3 days, at least 1 recipe
- is waiting for that system.
-
-* Delayed Jobs
-
- * they have a job which is more than 14 days old but still contains Queued
- recipes
-
-The given limits would all be server configuration options, with these
-values as the defaults.
-
-As long as a user triggers one of the alerts, then once a day they would get
-an email with the subject line::
-
- [Beaker] Usage report for <name> (<date>)
-
-The usage report would contain up to three sections, corresponding to the
-different alert conditions:
-
-* Expiring Reservations
-* Open Loans & Reservations for In Demand Systems
-* Delayed Jobs
-
-For expiring reservations, the time of expiration would be given along with
-the FQDN of the system.
-
-For in demand systems, the duration of the current loan or reservation would
-be given, the number of recipes currently waiting, and then the FQDN of the
-system. Loans and reservations will be shown separately.
-
-For purposes of the usage report, waiting recipes would be those that:
-
-* are at least 1 hour old (filtering out transient noise due to new jobs being
- processed and scheduled)
-* would be able to run on this system if it was in Automated mode and neither
- loaned to this user nor reserved by them.
-
-For delayed jobs, the time since the job was submitted would be given, along
-with a link to the job details page.
-
-An example report would look like this::
-
- =========
- [Beaker] Usage report for <name> (<date>)
- =========
- Hi <name>,
-
- Your reservations of the following systems in <Beaker instance FQDN> are
- going to expire within 24 hours. If you wish to ensure you retain the
- contents of these systems, please extend your reservation.
-
- Expiry Date FQDN
- 2014-05-15 05:18:01 +10:00 host.beakerlab.example.com
-
- The following systems have been allocated to you in <Beaker instance FQDN>
- for more than <X> days and have other recipes queued for execution.Please
- return them if you are no longer using them.
-
- Duration Waiting FQDN
- 7 days 1 recipe host2.beakerlab.example.com
-
- The following jobs you submitted to <Beaker instance FQDN> have been queued
- for more than <X> days. Please cancel them if they are no longer relevant,
- or perhaps arrange a loan of an appropriate system or systems
-
- Start time Delayed Job
- 2014-05-15 05:18:01 +10:00 https://<Beaker instance FQDN>/jobs/4594
-
- =========
-
-Deferred features
------------------
-
-* The usage e-mail covers outstanding reservations, but it does not currently
- include information about outstanding loans. This is because Beaker does not
- track the start date of loans apart from in the system history, which cannot
- be efficiently queried for generating the usage e-mail.
-
-* In future, when Beaker supports loan expiry, the usage e-mails could be
- updated to include loans expiring soon (in addition to reservations expiring
- soon).
-
-* In future, it would be possible to build a dashboard page that displays users' systems
- and jobs. Then we can use it in the email template to give users an overview of their
- Beaker usage.
diff --git a/dev/proposals/custom-distros.rst b/dev/proposals/custom-distros.rst
deleted file mode 100644
index d067ab6..0000000
--- a/dev/proposals/custom-distros.rst
+++ /dev/null
@@ -1,161 +0,0 @@
-.. _custom-distros:
-
-Handling Custom Distros
-=======================
-
-:Author: Dan Callaghan
-:Status: Implemented
-:Target Release: `0.18 <https://beaker-project.org/docs/whats-new/release-0.18.html#better-support-for-custom-distros>`__
-
-This document proposes a number of backwards-compatible changes to Beaker's
-kickstart templates, to make it easier to use custom distros without modifying
-Beaker's source code. Here "custom distros" means distros which still use the
-Anaconda installer but identify themselves as something other than Fedora, Red
-Hat Enterprise Linux, or CentOS [#centos-support]_.
-
-Background and rationale
-------------------------
-
-Beaker currently uses a separate kickstart template for each distro family
-(``RedHatEnterpriseLinux6``, ``RedHatEnterpriseLinux7``, etc).
-
-In addition, Beaker's templates and source code contain a large number of
-conditionals which check for hardcoded distro family names to decide what the
-desired kickstart output should be. In some cases features are assumed to be
-present, and disabled for some older distro families. In other cases, features
-are conditionally enabled only for certain hardcoded distro families.
-
-The end result is that a new distro family will effectively be treated as
-equivalent to RHEL6 unless all the relevant conditional logic in Beaker is also
-updated. Adding support for new distro families which aren't based on RHEL6
-therefore means modifying Beaker's source code --- it cannot be done by the
-Beaker administrator.
-
-The number of "custom distros" (particularly ones built on newer technology
-like RHEL7) is expected to continue growing in the near future, therefore
-Beaker needs better mechanisms for handling them.
-
-Proposed changes
-----------------
-
-Runtime checks inside bash scriptlets
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Most of the template conditionals which fall inside bash scriptlets (kickstart
-``%pre`` and ``%post`` sections) can be converted to perform an equivalent
-conditional check at runtime in the script itself.
-
-For example, the ``rhts_post`` kickstart snippet currently has a conditional
-block which assumes that the RHEL6 readahead service only exists for the
-``RedHatEnterpriseLinux6`` family. The snippet can instead check for the
-presence of :file:`/etc/sysconfig/readahead` at runtime, so that it also takes
-effect on other RHEL6-derived distros which have the RHEL6 readahead service.
-
-Similarly, there are a number of conditional blocks throughout the kickstart
-snippets which use wget for downloading if the family name matches RHEL3--5,
-otherwise they use curl. These conditionals can be replaced with a bash
-function which uses either wget or curl depending on which one is available at
-runtime.
-
-Feature variables
-~~~~~~~~~~~~~~~~~
-
-Other template conditionals cannot be converted to runtime checks because they
-are related to the kickstart syntax or package selection. These conditionals
-can be converted to check for the presence or absence of a kickstart metadata
-variable instead. Beaker will populate these "feature variables" automatically,
-based on the same logic currently used in the templates.
-
-In addition, the conditionals will all be inverted. Currently they are written
-as progressive enhancements: they assume the absence of a feature, and enable
-it for recognized distro families. This will be flipped so that Beaker always
-assumes the latest syntax and features *are* supported, and then conditionally
-disables them as necessary on older distros.
-
-For example, the ``rhts_partitions`` snippet currently has a (quite
-complicated) conditional block which enables the ``--type`` option for the
-``autopart`` command only for RHEL7 and Fedora releases from 18 onwards. The
-snippet can instead check if the ``has_autopart_type`` variable is defined.
-Beaker will define this variable by default, unless it recognizes that the
-distro is Fedora older than 18 or RHEL/CentOS older than 7.
-
-Default kickstart template
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Beaker currently expects to find a kickstart template named after the distro
-family. If none is found, Beaker cannot provision the distro. As a consequence,
-every new distro family to be supported by Beaker requires adding a new
-template (typically copied and modified from the Fedora or RHEL family on which
-it is based).
-
-Instead, Beaker will fall back to using a ``default`` template if no other
-matching template can be found. The ``default`` template will be based on the
-existing Fedora template, modified so that it also produces the desired output
-for RHEL7 and RHEL6. The existing templates for those families will be deleted
-from Beaker's source in favour of the ``default`` template, although any
-site-specific templates for those families will continue to be used as before.
-
-In future the kickstart templates for older RHEL families could also be
-replaced with the ``default`` template, after suitable conditionals are added
-to it to account for the missing features in those older families. However
-there is negligible benefit in doing this, since new custom distros are
-unlikely to be based on those older releases.
-
-Advantages of the approach
---------------------------
-
-When an unrecognised distro is imported, it will effectively be treated as the
-latest Fedora release. Beaker will fall back to using ``default`` kickstart
-template, and the aforementioned "feature variables" will be populated under
-the assumption that all features are supported.
-
-The Beaker administrator will also have complete control over the conditional
-kickstart behaviour for each OS major, by setting kickstart metadata variables
-on the OS major in their Beaker installation. This works equally well for
-distros Beaker knows about (for example, you could set ``!has_systemd`` in the
-install options for ``RedHatEnterpriseLinux7`` to override Beaker's default
-assumption that RHEL7 has systemd) or for completely unrecognised distros.
-The feature variables will be documented alongside the other kickstart metadata
-variables, to make it easier for administrators to figure out what variables
-they might need to set when using a custom distro in Beaker.
-
-Rather than having conditionals strewn throughout Beaker's source code and
-templates, the existing rules based on hardcoded distro families (for example,
-``RedHatEnterpriseLinux7`` has systemd) will be centralized to a single method
-in Beaker's source. That will make it easier to update the logic in future as
-the distros evolve.
-
-Backwards compatibility
------------------------
-
-This proposal preserves backwards compatibility for all existing custom
-snippets and templates. All existing variable names and template inheritance
-orders will be kept unchanged.
-
-The generated kickstarts will be mostly unchanged for existing supported
-distros. To simplify the implementation, some differences across the templates
-will be regularized, but only when it has no effect on the meaning of the
-generated kickstart: the order of some commands will change, and some commands
-which have no effect (such as ``key --skip`` on RHEL6) will be dropped.
-
-Open questions
---------------
-
-Aside from the kickstart templates, distro names are hardcoded in some other
-parts of Beaker as well. This proposal does not attempt to address these
-issues.
-
-* Harness repos are identified by distro family, and if a repo is not found the
- distro cannot be used in recipes. However, the Beaker administrator can
- always create a harness repo for a custom distro, by copying from or
- symlinking to an existing repo for a compatible distro.
-
-* The ``beaker-import`` command uses some hardcoded product names in order to
- distinguish between different metadata formats (:issue:`1070575`).
-
-.. rubric:: Notes
-
-.. [#centos-support] Beaker has historically supported CentOS only on
- a best-effort basis and not consistently. The changes in this proposal will
- make it possible to consistently treat CentOS as equivalent to RHEL for
- kickstart templating purposes.
diff --git a/dev/proposals/dynamic-virtualization.rst b/dev/proposals/dynamic-virtualization.rst
deleted file mode 100644
index 63f759d..0000000
--- a/dev/proposals/dynamic-virtualization.rst
+++ /dev/null
@@ -1,201 +0,0 @@
-.. _proposal-dynamic-virtualization:
-
-OpenStack Based Dynamic Virtualization
-======================================
-
-:Author: Nick Coghlan
-:Status: Implemented
-:Release: `0.17 <https://beaker-project.org/docs/whats-new/release-0.17.html#openstack-as-dynamic-virtualization-backend>`__
-
-
-Abstract
---------
-
-While Beaker's distinguishing feature is the ability to request distinctive
-hardware when provisioning systems (rather than having to name the target
-system explicitly, or only getting access to a generic virtual machine),
-Beaker jobs still often involve running code that doesn't need to be on
-any particular hardware.
-
-The dynamic virtualization support is designed to integrate a Beaker lab with
-an external provisioning system, allowing Beaker to request access to
-additional generic compute resources in order to resolve these requests.
-Beaker's current dynamic virtualization support is based on oVirt Engine,
-and has several limitations that make it unusable in practice.
-
-Some of those issues are inherent in the fact that dynamic creation of
-ephemeral virtual machines is a task that oVirt doesn't handle well, so
-rather than fixing the problems directly, it is proposed that Beaker's
-dynamic virtualization support instead be redesigned to be based on
-OpenStack.
-
-
-Dependencies
-------------
-
-None.
-
-
-Background
-----------
-
-Beaker 0.10 added the ability to dynamically provision virtual machines
-in `oVirt Engine <http://beaker-project.org/docs/admin-guide/ovirt.html>`__.
-While this feature works correctly at small scale, it suffers from several
-issues that prevent scaling to larger instances.
-
-During the development of this feature, it also became clear that oVirt
-simply wasn't a good fit for the problem we're trying to solve with Beaker's
-dynamic virtualization. oVirt focuses on the "high availabilty" kind of
-virtualization, where a virtual machine is created once, and can then be
-migrated between host machines to cope with hardware failure, planned
-maintenance, upgrades, etc. By contrast, Beaker needs to create dynamic,
-relatively shortlived virtual machines on demand, and then throws them
-away when the recipe set completes execution. This use case is a much
-better fit for OpenStack than it is for OpenShift.
-
-Furthermore, it became clear that oVirt didn't provide a clear path
-towards image based provisioning for Beaker (although more recent versions
-of oVirt do support integration with the OpenStack Glance image library, and
-the lack of a straightforward approach to remotely capturing console log
-details was also problematic (as some Beaker features, like automatic panic
-detection, do not work without remote console log access, and the console
-log data is also often invaluable when debugging test and system failures).
-
-
-Proposal
---------
-
-The proposal is to take the current dynamic virtualization feature, and
-replace the current oVirt based provisioning components in the scheduler
-with new components that use OpenStack instead. The existing support for
-oVirt integration will be removed entirely.
-
-This proposal is tracked in Bugzilla as issue :issue:`1040239`.
-
-
-Minimum OpenStack version
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Due to the significant changes to network configuration support between
-OpenStack Grizzly and Havana, it is proposed that Beaker only support
-OpenStack Havana and later.
-
-
-Associating lab controllers with OpenStack regions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Replacing the existing association of lab controllers with specific oVirt
-data centres, Beaker will allow each lab controller to optionally be
-associated with an `OpenStack region
-<http://docs.openstack.org/trunk/openstack-ops/content/cells_regions.html>`__.
-
-It is expected that the associated region be in reasonably close proximity
-to any physical systems associated with that lab controller, as Beaker may
-provision a mixture of physical systems and dynamically created virtual
-machines for a single recipe set.
-
-Pure virtual labs that are associated with an OpenStack region, but no
-physical machines *will* be supported.
-
-
-Host filtering
-~~~~~~~~~~~~~~
-
-Beaker will translate memory and virtual CPU requirements for x86 and x86_64
-hosts into suitable queries against the available VM "flavours" in OpenStack.
-If a suitable flavour is available, and there are no other specific hardware
-requirements for the recipe, then that recipe will be considered a candidate
-for dynamic virtualization.
-
-As with the existing dynamic virtualization support, Beaker will favour the
-use of dynamic resources whenever the host filtering requirements allow it.
-
-
-Provisioning
-~~~~~~~~~~~~
-
-The initial iteration of Beaker's OpenStack based dynamic virtualization will
-not directly use image based provisioning.
-
-Instead, Beaker will rely on a common `iPXE <http://ipxe.org/download>`__
-image, which will allow Beaker to point to the appropriate kernel and
-initrd URLs dynamically, and allow Anaconda to handle the installation as
-usual.
-
-This approach is preferred for the initial implementation, as many Beaker
-recipes currently take advantage of Anaconda specific features (most of
-the post install customisation explicitly uses kickstart specific syntax),
-and Beaker itself relies on Anaconda to handle tasks like disk partitioning,
-package installation and yum repo configuration.
-
-With the assumption of Anaconda based provisioning currently pervasive in
-the Beaker server code, deferring image based provisioning to a later
-release should significantly reduce the amount of change needed for the
-initial OpenStack integration.
-
-This proposed approach to provisioning is very similar to that taken by
-Rackspace in the design of their `boot.rackspace.com
-<http://rackerlabs.github.io/boot.rackspace.com/>`__ utility scripts.
-
-
-Disk configuration
-~~~~~~~~~~~~~~~~~~
-
-The initial iteration of the OpenStack integration will *not* support recipes
-which request a particular disk configuration in their host requirements,
-and will not support the use of persistent block storage volumes.
-
-Instead, virtual machines will simply receive the amount of ephemeral storage
-allocated for the system flavour that satisfies their memory and virtual CPU
-requirements.
-
-
-Network configuration
-~~~~~~~~~~~~~~~~~~~~~
-
-The initial iteration of the OpenStack integration will use a predefined
-subnet that must be specified as part of the lab controller configuration in
-Beaker.
-
-Systems on this subnet must have the same level of network access as any
-other systems in that Beaker lab. In particular, they must be able to access
-the lab controller (to report results), the web server that hosts the
-distro trees and any custom repository hosts that are supported by that
-lab.
-
-
-Console logging
-~~~~~~~~~~~~~~~
-
-Beaker will make use of the console APIs in OpenStack to ensure that console
-logs for dynamically provisioned systems are captured correctly
-(:issue:`950903`).
-
-
-Deferred features
------------------
-
-The following additional features are under consideration, but have been
-deliberately omitted in order to reduce the complexity of the initial
-iteration of the design:
-
-* Provisioning directly from predefined OpenStack images. While this
- feature is expected to be implemented eventually, adding the ability to
- support cloud-init in addition to Anaconda kickstarts is better handled as
- a separate follow-on activity (also see :issue:`1108455`).
-
-* Using OpenStack Cinder to support alternative requested block storage
- configurations (for example, multiple disks of particular sizes).
-
-* Using OpenStack Neutron to dynamically create individual subnets for
- each recipe set.
-
-
-Rejected alternatives
----------------------
-
-An earlier draft of this proposal suggested building `bootstrap images
-<https://github.com/redhat-openstack/image-building-poc>`__ when a distro
-tree was imported and uploading them to glance. Dan Callaghan suggested
-using iPXE instead, which looks like it should be a much simpler alternative.
diff --git a/dev/proposals/effective-job-priorities.rst b/dev/proposals/effective-job-priorities.rst
deleted file mode 100644
index 50623a5..0000000
--- a/dev/proposals/effective-job-priorities.rst
+++ /dev/null
@@ -1,134 +0,0 @@
-.. _proposal-effective-job-priorities:
-
-Effective Job Priorities
-========================
-
-:Author: Nick Coghlan
-:Status: Deferred
-:Target Release: TBD
-
-
-Abstract
---------
-
-This proposal adds the ability for system owners to provide shared access
-to systems, while allowing jobs submitted on behalf of particular groups to
-be given precedence when the system is in high demand.
-
-
-Proposal deferral
------------------
-
-Further work on this proposal is currently deferred, pending research into
-the Apache Mesos scheduling meta-framework, and its potential suitability
-as a replacement for the current bespoke Beaker scheduler.
-
-
-Dependencies
-------------
-
-This proposal depends on:
-
-* :ref:`proposal-enhanced-user-groups`
-* :ref:`proposal-access-policies`
-* :ref:`proposal-event-driven-scheduling`
-
-
-Proposal
---------
-
-Granting access to systems in Beaker is currently "all or nothing": if you
-grant another user permission to run jobs on a system you own, then the
-scheduler will consider their jobs to have as much right to make use of
-your systems as your own jobs do. The existing "Urgent", "High", "Normal",
-"Medium", "Low" prioritisation scheme is applied globally to all recipes
-currently queued whenever a system becomes available for automated use.
-
-This proposal takes advantage of features added by the
-:ref:`proposal-enhanced-user-groups`, :ref:`proposal-access-policies` and
-:ref:`proposal-event-driven-scheduling` proposals to introduce the concept
-of "Maximum effective priority" for the execution of jobs on a system.
-
-The intent is to allow a system owner to, for example, leave the maximum
-effective priority for jobs submitted on behalf of their own primary user
-group at "Urgent", while restricting the maximum effective priority for all
-other user groups to "Medium". With those settings, when the system in
-question becomes "pending" (see :ref:`proposal-pending-systems-processing`)
-then the queued recipes will be considered for execution in the following
-precedence order, sorting first by effective priority, and then by nominal
-priority::
-
- Urgent, Urgent (job submitted on behalf of designated group)
- High, High (job submitted on behalf of designated group)
- Normal, Normal (job submitted on behalf of designated group)
- Medium, Urgent (job NOT submitted on behalf of designated group)
- Medium, High (job NOT submitted on behalf of designated group)
- Medium, Normal (job NOT submitted on behalf of designated group)
- Medium, Medium (any job)
- Low, Low (any job)
-
-The proposed mechanism for implementation is to change the "can submit
-automated jobs" permission on access policies to record a list of
-"Group, Maximum Effective Priority" pairs, rather than the simple
-list of groups supported by the initial access policy design.
-
-When the recipe queue is being sorted for a "Pending System" scheduling
-event, then the effective priority for any given recipe will be
-determined by looking at the associated group for the recipe's job
-(defaulting to the "Everybody" group if the recipe was not submitted on
-behalf of a group). The maximum effective priority for that recipe is the
-*highest* maximum effective priority that group has on any of the system
-pools to which the system belongs.
-
-The actual effective priority of the recipe is then the lower of its
-maximum effective priority and the nominal priority set on the job
-itself.
-
-Finally, sorting of the recipe queue is then by the
-(Effective Priority, Nominal Priority) pair rather than solely by the
-nominal priority:
-
-+------------+------------+
-| Effective | Nominal |
-| Priority | Priority |
-+============+============+
-| Urgent | Urgent |
-+------------+------------+
-| High | Urgent |
-| +------------+
-| | High |
-+------------+------------+
-| Normal | Urgent |
-| +------------+
-| | High |
-| +------------+
-| | Normal |
-+------------+------------+
-| Medium | Urgent |
-| +------------+
-| | High |
-| +------------+
-| | Normal |
-| +------------+
-| | Medium |
-+------------+------------+
-| Low | Urgent |
-| +------------+
-| | High |
-| +------------+
-| | Normal |
-| +------------+
-| | Medium |
-| +------------+
-| | Low |
-+------------+------------+
-
-
-Open Questions
---------------
-
-* Should we also support setting a "Minimum Priority" for groups? It's
- not clear this is necessary, and it *would* complicate the design and
- implementation. Current proposal is to leave it out of the initial
- implementation, and add it later if a compelling use case is presented
- that the current design can't address.
diff --git a/dev/proposals/enhanced-user-groups.rst b/dev/proposals/enhanced-user-groups.rst
deleted file mode 100644
index 5d151be..0000000
--- a/dev/proposals/enhanced-user-groups.rst
+++ /dev/null
@@ -1,554 +0,0 @@
-.. _proposal-enhanced-user-groups:
-
-Enhanced User Groups
-====================
-
-:Authors: Dan Callaghan, Nick Coghlan, Raymond Mancy
-:Status: Implemented
-:Initial Release: `0.13 <http://beaker-project.org/docs/whats-new/release-0.13.html>`__
-:Final Release: `0.14 <http://beaker-project.org/docs/whats-new/release-0.14.html>`__
-
-Abstract
---------
-
-This proposal adds additional self-management capabilities for Beaker's
-user groups, adding the ability for a job to be owned by a group,
-and submitting a job via a :term:`submission delegate`.
-
-
-Dependencies
-------------
-
-None.
-
-
-Proposal
---------
-
-Under Beaker's current group design, all group management is carried out
-by Beaker administrators, and groups can own systems, but not jobs.
-
-This proposal enhances the capabilities of the existing group model by:
-
-* allowing users to manage their own groups, rather than requiring
- administrator involvement
-* allowing administrators to create groups that are automatically derived
- from groups already defined in an LDAP server
-* allowing jobs to be submitted on behalf of a group by group members.
-* allowing jobs to be submitted by a :term:`submission delegate`.
-
-A Beaker user can be in zero or more groups, and any Beaker user may
-create a new group at any time. Group members may be marked as owners of
-that group, which grants additional permissions. The initial creator of a
-group is automatically marked as an owner at the time of creation.
-
-All members of a group are able to submit jobs on behalf of the group, and
-have full access to modify jobs submitted on behalf of the group.
-
-Jobs submitted on behalf of a group are called "group jobs", while other
-jobs are called "single-user jobs".
-
-Submission delegates are able to submit jobs on behalf of a user, but
-are only able to modify the jobs they submit. A :term:`submission delegate`
-does not gain access to modify other jobs that the user can modify.
-
-
-Group ownership
-~~~~~~~~~~~~~~~
-
-Group ownership permissions grant a user the ability to:
-
-* add and remove group members
-* grant and revoke group ownership permissions
-* grant and revoke job modification permissions
-* update the group's display name
-
-As a group may have multiple owners, "group ownership" may sometimes
-be referred to as "group co-ownership".
-
-
-Group jobs
-~~~~~~~~~~
-
-When a job is submitted on behalf of a group, any members of that group
-will have the same level of access to and control over the job as the
-original submitter.
-
-Submission delegates
-~~~~~~~~~~~~~~~~~~~~
-
-Users may nominate additional :term:`submission delegates` that are
-permitted to submit and modify jobs on the user's behalf.
-These users will retain job modification privileges only for the
-jobs they submit.
-
-
-General use cases
------------------
-
-The primary use case for the additional features is to simply improve the
-scalability of Beaker usage in large organisations, by:
-
-* removing the installation administrators as a bottleneck for group updates.
-* making it possible to derive group membership directly from an LDAP
- server.
-* allowing a team of submitters to share responsibility for a set of jobs,
- rather than limiting access to the specific user that carried out the
- actual submission.
-
-In addition, these changes aim to make it easier for users to set up
-automated systems that submit jobs on their behalf (for example, as an
-event triggered by a successful build on a continuous integration server).
-
-
-Proposed user interface
------------------------
-
-Self-service user groups
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Creating ad hoc groups
-^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to create a new group. (:issue:`908172`)
-
-Through the web UI:
-
- Select "Hello -> My Groups" from the menu, then click "Create". Enter
- a group name and display name, and click "Create".
-
-Through the ``bkr`` cli::
-
- bkr group-create --display-name="My New Group" <mynewgroup>
-
-A new group is created, with one member (you) who is also a group owner.
-The change is recorded in the "Group Activity" log.
-
-
-Creating LDAP-derived groups
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I am a Beaker administrator and I want to create a new group whose
- membership is populated from LDAP. (:issue:`908173`)
-
-Through the web UI:
-
- Select "Admin -> LDAP Groups" from the menu, then click "Create". Enter
- the group name, which must correspond to the name of a group in your
- LDAP directory.
-
-Through the ``bkr`` cli::
-
- bkr group-create --ldap <mygroup>
-
-A new group is created, whose membership is populated from the LDAP
-directory configured in your Beaker installation. An admin can refresh all
-currently defined LDAP groups from LDAP by running ``beaker-refresh-ldap``
-on the main Beaker server. Beaker will ship with a cron job that runs
-``beaker-refresh-ldap`` once per day, but the administrators of a
-particular installation may choose to refresh the group membership more
-frequently.
-
-Note that LDAP groups cannot be updated through Beaker. They have no
-owners.
-
-
-Viewing group details
-^^^^^^^^^^^^^^^^^^^^^
-
-* I want to view the details of a group. (:issue:`541282`)
-
-Through the web UI:
-
- Select "Hello -> My Groups" from the menu, then click the name of the
- group you are interested in to go to its group page.
-
-Through the ``bkr`` cli::
-
- bkr group-members <mygroup>
-
-
-Updating group details
-^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to update the details of a group I own (:issue:`952978`).
-
-Through the web UI:
-
- Select "Hello -> My Groups" from the menu, then click the name of the
- group you are interested in to go to its group page.
-
- To update the display name for the group, click
- "Edit Group", update the group details, then click "Save Changes".
-
-Through the ``bkr`` cli::
-
- bkr group-modify --display-name="My Group" <mynewgroup>
-
-The group details are updated and the change is recorded in the
-"Group Activity" log.
-
-
-Updating group membership
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to add other users to a group I own. (:issue:`908176`)
-
-Through the web UI:
-
- Go to the group page. Under the membership list, enter the user's
- username and click "Add to Group".
-
-Through the ``bkr`` cli::
-
- bkr group-modify --add-member=<someusername> <mygroup>
-
-The user is added to the group. The change is recorded in the
-"Group Activity" log.
-
-* I want to remove a member from a group I own. (:issue:`908176`)
-
-Through the web UI:
-
- Go to the group page. Find the user in the membership list, and click "Remove".
-
-Through the ``bkr`` cli::
-
- bkr group-modify --remove-member=<someusername> <mygroup>
-
-The user is removed from the group. The change is recorded in the
-"Group Activity" log.
-
-
-Updating group permissions
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to grant another member owner rights to a group I own.
- (:issue:`908174`)
-
-Through the web UI:
-
- Go to the group page. Find the other user in the membership list,
- check the checkbox in the "Owner" column, then click "Save".
-
-Through the ``bkr`` cli::
-
- bkr group-modify --grant-owner=<someusername> <mygroup>
-
-The user is granted owner rights and the change is recorded in the
-"Group Activity" log.
-
-* I want to revoke another member owner rights to a group I (co-)own.
- (:issue:`908174`)
-
-Through the web UI:
-
- Go to the group page. Find the other user in the membership list,
- uncheck the checkbox in the "Owner" column, then click "Save".
-
-Through the ``bkr`` cli::
-
- bkr group-modify --revoke-owner=<someusername> <mygroup>
-
-The user's ownership rights for the group are revoked and the change is
-recorded in the "Group Activity" log.
-
-
-Group job management
-~~~~~~~~~~~~~~~~~~~~
-
-Submitting group jobs
-^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to submit a job for a particular group (of which I am a member).
- (:issue:`908183`)
-
-Through the job XML:
-
- Add an optional attribute ``group="somegroup"`` to the ``<job/>`` element
- directly to the job XML.
-
-Through the ``bkr`` cli::
-
- Pass the ``--job-group=somegroup`` option to a workflow command.
-
-The job will be owned by that group and the user that submitted the job.
-There can be only one associated group per job, thus multiple groups having
-ownership of a single job is not possible.
-
-All members of the group will be able to ack/nack, change priority,
-edit whiteboard, change retention tag, delete the job, etc, as if they were
-the submitter of the job. The root password used in the job will be the
-group root password (if one is set), otherwise it will be the root
-password set in the preferences of the :term:`submitting user`.
-The public SSH keys of all group members will be added to
-``/root/.ssh/authorized_keys``.
-
-
-Viewing shared jobs
-^^^^^^^^^^^^^^^^^^^
-
-* I want to view a list of jobs for all groups of which I am a member.
- (:issue:`908185`)
-
-The default filter for the "My Jobs" page will include all jobs the user
-can manage, including those the user submitted themselves, as well as
-those submitted on behalf of a group where the user has job modification
-permissions.
-
-* I want to view a list of jobs for a particular group. (:issue:`952980`)
-
-Both the "My Jobs" page and the main job list will allow filtering by
-the owning group. This will permit users to display jobs owned by
-particular groups (whether they are a member of those groups or not), as
-well as displaying only the jobs that were not submitted on behalf of a
-group at all.
-
-
-Root password configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to set the shared root password to be used in all jobs for a
- particular group. (:issue:`908186`)
-
-Through the web UI:
-
- Go to the group page. Enter the root password in the "Root Password" field
- and click "Save". The root password may be given in hashed form (suitable
- for inclusion in ``/etc/shadow``) or in the clear.
-
-Through the ``bkr`` cli::
-
- bkr group-modify --root-password=<thevalue>
-
-The given root password will be used when provisioning jobs for this group.
-It will be visible on the group page to other members of the group. If the
-password is given in the clear Beaker will *not* automatically hash it
-before storing, to make it easier to share amongst the group (This
-behaviour deliberately differs from that for individual root passwords set
-on the Preferences page - when given in the clear, individual passwords are
-automatically hashed before storage).
-
-Changes to the group's root password are recorded in the "Group Activity"
-log. The activity log only records when the change occurred, and the user
-that made the change - the password itself is not recorded in the activity
-log, not even in hashed form).
-
-.. note::
-
- It is *strongly* recommended that group members upload their public
- SSH keys (which will be automatically added to systems provisioned
- for group jobs) rather than setting a shared root password for the
- group.
-
-
-Submission delegation
-~~~~~~~~~~~~~~~~~~~~~
-
-.. note::
- Submission delegation is not part of the initial release in Beaker 0.13.
-
-
-Submitting delegated jobs
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to submit a job for a particular user, using an account that has
- been nominated as a :term:`submission delegate`. (:issue:`960302`).
-
-The user interface for submitting a job via a :term:`submission delegate`
-is to assign the :term:`job owner` via the ``user`` attribute on the job element.
-
-The additional functionality needed to handle the :term:`submission delegate`
-case is in assigning resources based on the :term:`job owner`, not the
-:term:`submission delegate`.
-
-
-Viewing submission delegates
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to view the list of :term:`submission delegates` for a user.
- (:issue:`960302`).
-
-The list of :term:`submission delegates` should be included on the user's
-preferences page.
-
-
-Updating submission delegations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* I want to add a user that can submit jobs on my behalf.
- (:issue:`960302`).
-
-Through the web UI:
-
- Go to the user preferences page. Under the :term:`submission delegate` list, enter the user's
- username and click "Add".
-
-Through the ``bkr`` cli::
-
- bkr user-modify --add-submission-delegate=<someusername> [<username>]
-
-The new :term:`submission delegate` is added and the change is recorded in the
-"User Activity" log.
-
-* I want to revoke a submission delegate's permission to submit jobs on my behalf.
- (:issue:`960302`)
-
-Through the web UI:
-
- Go to the user preferences page. Find the user in the
- :term:`submission delegates` list, and click "Remove".
-
-Through the ``bkr`` cli::
-
- bkr user-modify --remove-submission-delegate=<someusername> [<username>]
-
-The :term:`submission delegate` is removed and the change is recorded in the "User Activity"
-log.
-
-
-Impact on other existing features
----------------------------------
-
-Currently, group members have some limited control over single-user jobs
-submitted by members of the same group. This feature will be deemed
-deprecated and will be removed in a later release (probably Beaker 1.1).
-This should give users of any existing installations adequate opportunity
-to start explicitly marking jobs where group access is needed as group jobs.
-
-
-Upgrading Existing Beaker Installations
----------------------------------------
-
-All members of existing groups in a Beaker installation will be granted
-job modifications permissions for each group where they are a member.
-
-This means that groups that already existed in a Beaker installations will
-not have any designated owners after the installation is upgraded. After
-upgrading, users and administrators of the Beaker installation will
-need to coordinate the initial allocation of ownership privileges to
-members of existing groups, as well as deciding which groups can be deleted
-and replaced with LDAP group references.
-
-
-Rejected Ideas
---------------
-
-An earlier iteration of the design used a "job modification" flag to allow
-group members that could only submit jobs, but not modify them. This
-approach was judged to be confusing, so has been replaced with the current
-submission delegation design (also see :issue:`952979` and
-`this beaker-devel thread`__).
-
-.. __: https://lists.fedorahosted.org/pipermail/beaker-devel/2013-April/000552.html
-
-
-
-Deferred Features
------------------
-
-These additional features are under consideration, but have been deliberately
-omitted in order to reduce the complexity of the initial iteration of the
-design:
-
-
-* Adding other groups as members of a group (:issue:`554802`). The initial
- iteration does not allow groups to be members of other groups, which
- introduces potential concerns about scalability in large organisations. A
- subgroups model, with an implementation based on the `Closure Table`_
- design, would address this concern. If there's time, we'll look into
- adding this to 1.0, otherwise it will be considered for inclusion in 1.1.
-
- The draft web UI design is the same as that for managing group members, but
- using the "Sub-group" list instead of the "Members" list. For the CLI::
-
- bkr group-modify --add-subgroup=<groupname> <mygroup>
- bkr group-modify --remove-subgroup=<groupname> <mygroup>
- bkr group-modify --grant-owner-subgroup=<groupname> <mygroup>
- bkr group-modify --revoke-owner-subgroup=<groupname> <mygroup>
- bkr group-modify --grant-modify-jobs-subgroup=<groupname> <mygroup>
- bkr group-modify --revoke-modify-jobs-subgroup=<groupname> <mygroup>
-
- Beaker will not permit a group to be a member of another group if it forms
- a cycle.
-
- This feature will also make it possible to have an LDAP-defined group as
- part of a group that also allows manual addition of members through
- Beaker.
-
- .. _Closure Table: http://stackoverflow.com/questions/192220/what-is-the-most-efficient-elegant-way-to-parse-a-flat-table-into-a-tree/192462#192462
-
-
-* Group descriptions. The display name only allows a short piece of text.
- Group descriptions could, for example, include external links or
- instructions on how to request group membership.
-
-* User-level self service to request group membership (including the
- associated queue interface for group owners to approve/deny requests),
- or to remove yourself from groups. This capability is likely to be added
- in a later iteration. In the meantime, the list of group owners will be
- visible in the web UI.
-
-* More fine-grained group permissions. The initial iteration has only three
- effective levels of access: job submission delegates, ordinary group
- members and group (co-)owners. It may be desirable to separate out the
- last level further in a future release:
-
- * Add/remove members (currently allowed for all co-owners)
- * Grant/revoke co-ownership (currently allowed for all co-owners)
- * Modify group display name and description (currently allowed for all co-owners)
-
- For ordinary members, it may also be desirable to separate out:
-
- * Ability to log into provisioned systems based on their SSH key (currently
- allowed for all group members with a public SSH key registered in Beaker)
- * Ability to ack/nack job results (currently allowed for all group members)
- * Ability to change the associated product (currently allowed for all
- group members)
- * Ability to change the job retention policy (currently allowed for all
- group members)
- * Ability to let submission delegates run jobs on group assets (currently
- allowed for all group members)
-
-* Group deletion. The initial iteration does not allow groups to be deleted,
- or even hidden. If subgroup management is added, and the associated UI
- includes some form of list for group selection, then it is likely that
- group owners will be granted the ability to mark a group as *hidden*, so
- it doesn't show up in such lists. Creating a usable UI for the
- :ref:`proposal-system-pools` proposal may also lead to this feature
- being implemented.
-
-* Default groups for job submission. The initial iteration always defaults to
- no group assocation for submitted jobs. It may be desirable to allow users
- to designate a "default group" for their jobs, such that members of that
- group will be granted access to their jobs if no other group is specified.
-
-* Changing the group of a job after submission. While this is potentially
- useful in some respects, it will mean that the state of the provisioned
- systems (at least the set of authorized SSH keys and potentially the
- root password) will no longer match the nominated group. It may make more
- sense to allow additional groups to be granted edit access on the job.
-
-* Updating the job matrix to allow limiting it to jobs submitted on behalf
- of a particular group. This would only be useful if irrelevant jobs were
- being submitted with relevant whiteboard settings, and there's a
- straightforward usage policy based workaround (making the
- whiteboard entries used with the job matrix more specific).
-
-
-.. glossary::
-
- submission delegates
- submission delegate
- A user that can submit and modify jobs on behalf of another user,
- and may or may not be a real user themselves (i.e they may be a
- service, script, etc).
-
- submitting user
- This is the user that is directly responsible for submitting a job, which
- may or may not be a submission delegate.
-
- job owner
- The actual owner of a job. In the absence of a submission
- :term:`submission delegate`, this is the same as the
- :term:`submitting user`.
diff --git a/dev/proposals/event-driven-scheduler.rst b/dev/proposals/event-driven-scheduler.rst
deleted file mode 100644
index f127bf2..0000000
--- a/dev/proposals/event-driven-scheduler.rst
+++ /dev/null
@@ -1,263 +0,0 @@
-.. _proposal-event-driven-scheduling:
-
-Event Driven Scheduling
-=======================
-
-:Author: Nick Coghlan
-:Status: Deferred
-:Target Release: TBD
-
-
-Abstract
---------
-
-The current Beaker scheduler operates on a batch processing model, repeatedly
-looping over the full set of submitted recipes, advancing them through the
-possible states in groups. That is, it looks for recipes to move from
-``new`` to ``processed``, then again for recipes to move from ``processed``
-to ``queued``, and so on.
-
-This approach leads to a number of unfortunate race conditions, including
-the possibility of recipes "jumping the queue" to access a rare system
-if that system becomes available while the scheduler is midway through a
-pass over the currently queued recipes. More seriously, it causes problems
-when scheduling multi-host recipesets that can only run on a limited number
-of systems: if two recipesets need systems A and B, and one gets system A,
-while the other gets system B, then the two recipesets will effectively
-deadlock, both waiting for each other in a classic ABBA race condition.
-
-This proposal describes a new, more event driven, scheduler design
-which avoids these race conditions, as well as enabling other features
-that cannot be supported with the current scheduler.
-
-This proposal also covers a plan to better separate out time spent
-provisioning systems from the time spent executing user submitted tasks.
-(that part can, and probably will, be separated out and implemented before
-the rest of the probosal)
-
-
-Proposal deferral
------------------
-
-Further work on this proposal is currently deferred, pending research into
-the Apache Mesos scheduling meta-framework, and its potential suitability
-as a replacement for the current bespoke Beaker scheduler.
-
-
-Dependencies
-------------
-
-None.
-
-
-Proposal
---------
-
-The specific proposal is that scheduling events will now occur in two
-distinct ways:
-
-1. "New job" scheduling events will occur when a new job is submitted to
- Beaker and Beaker attempts to assign the recipes within the job to
- currently idle systems.
-2. "Pending system" scheduling events will occur when a system is about
- to be marked as idle and Beaker first scans the recipe queue for a
- suitable recipe to schedule on that system.
-
-The existing scheduling loop will be retained for its secondary role in
-monitoring database consistency and correcting any discrepancies (for
-example, by aborting recipes where the requested distro tree has been
-removed from all registered lab controllers).
-
-This proposal does not depend on the introduction of any new asynchronous
-messaging infrastructure. Instead the current scheduling loop will be
-supplemented by two additional loops, one looking for new jobs and the
-other for pending systems.
-
-This approach has the advantage of not requiring any special processing
-at system startup to deal with unprocessed events left over from the
-previous shutdown. However, the design also supports moving away from a
-polling model if an asynchronous messaging system is adopted for internal
-communication between Beaker components (specifically the web UI/service
-and the background scheduling daemon) in the future.
-
-
-Viable systems, idle systems and pending systems
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For the purposes of this proposal, the phrase "viable system" refers to
-a system that is configured for automated use and meets the requirements
-needed to run a given recipe. The full set of viable systems for a recipe
-may include systems that are already allocated to another recipe, as well
-as a VM dynamically allocated through the oVirt Engine integration.
-
-The phrase "idle system" refers to a system that is configured for automated
-use and is currently in the pool of systems available to handle new jobs.
-Systems currently running a recipe are never considered idle.
-
-The phrase "idle pool" refers to all currently idle systems. It also refers
-to successful dynamic allocation of a VM through the oVirt Engine
-integration.
-
-The phrase "pending system" refers to a system that is configured for
-automation, but is currently neither running a recipe nor part of the idle
-pool. This may be because the system has just finished running a recipe,
-or because it has just been configured for automated operation.
-
-
-"New Job" processing
-~~~~~~~~~~~~~~~~~~~~
-
-The current recipe state machine includes the states::
-
- new
- processed
- queued
- scheduled
- waiting
- running
- completed
-
- cancelled
- aborted
-
-With the current scheduler, all successfully completed recipes pass through
-the full sequence of states from ``new`` to ``completed``. A recipe may jump
-from any state other than ``completed`` directly to ``cancelled`` or
-``aborted``.
-
-Under this proposal, the following changes occur:
-
-* The ``processed`` state is removed (along with the associated behaviour
- of caching an initial search for viable systems).
-* A new state ``assigned`` is added to indicate when a recipe has been
- assigned to a particular lab controller, but not yet scheduled on a
- specific system. (alternative: reuse the existing 'processed' state
- for this purpose instead of deleting and adding a new state?).
-
-When handling a "New job" scheduling event:
-
-* recipe sets within the job will be processed in arbitrary order
-* recipes within a recipe set will be processed in arbitrary order
- (alternative: process recipes in order from fewest viable systems
- to most viable systems?)
-* all recipes in one recipe set will be processed before processing
- the next recipe set
-* a recipe will be moved directly from ``new`` to ``scheduled`` if a
- viable system is found in the idle pool. In this case, all other
- recipes in the same recipe set as the scheduled recipe will be
- moved to ``assigned``.
-* recipes in ``assigned`` will be moved to ``scheduled`` if a
- suitable idle system controlled by the appropriate lab
- controller is found.
-* if no recipes in a recipe set are scheduled, then every recipe in the
- recipe set will be moved to ``queued``.
-
-While this proposal does *not* make any changes to the way a specific
-system is chosen from the idle pool when multiple viable systems are
-available, it does lay the groundwork for such changes in the future by
-cleanly separating the "New Job" processing (where job and job owner
-preferences will guide the selection) from the "Pending System"
-processing (where system preferences will guide the selection).
-
-.. _proposal-pending-systems-processing:
-
-"Pending System" processing
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Part of this proposal is to add an explicit state machine for current
-system usage, rather than continuing to rely on the implicit state machine
-derived from other attributes.
-
-The proposed set of states for the new usage state machine are as follows::
-
- idle
- scheduled
- waiting
- installing
- running
- pending
-
-When the system condition is Broken, systems will always be ``idle``.
-
-When the system condition is Manual, systems will be ``running`` when
-reserved by a user, ``waiting`` and then ``installing`` when being
-provisioned in response to a reservation request, but otherwise ``idle``.
-
-When the system condition is Automated, systems will be:
-
-* ``running`` when the associated recipe is ``running``
-* ``installing`` when the associated recipe is ``installing``
-* ``waiting`` when the associated recipe is ``waiting``
-* ``scheduled`` when the associated recipe is ``scheduled``
-* ``pending`` when a determination is needed as to whether the system
- should start running a queued recipe or be marked as ``idle``
-* ``idle`` in any other case
-
-The rationale for the duplication of states been systems and recipes is
-easier tracking of both system-oriented and recipe-oriented metrics. See
-:ref:`system-usage-monitoring` below.
-
-Systems will be marked as ``pending`` (triggering a "Pending system"
-scheduling event) in the following cases:
-
-* A new system is added with its condition set to Automated
-* The condition of an existing system is changed to Automated
-* A system with its condition set to Automated finishes execution of a
- recipe (either because the final task completed successfully, or because
- the recipe was cancelled or aborted)
-
-When handling a "Pending system" scheduling event
-
-* the currently ``assigned`` recipes for the system's lab controller are
- searched for a suitable recipe. If one is found, both the system and the
- recipe will be moved to ``scheduled``.
-* if the system remains ``pending``, all currently ``queued`` recipes are
- searched for a suitable recipe. If one is found, both the system and the
- recipe will be moved to ``scheduled``. All other recipes in the same
- recipe set will be moved to ``assigned``.
-* if the system still remains ``pending``, it will be moved to ``idle``.
-
-In this initial proposal, the ``assigned`` and ``queued`` recipes are still
-sorted solely by overall job priority when looking for a suitable recipe.
-While this is valuable in its own right (it eliminates a number of race
-conditions and queue jumping that is possible in the current design), it
-also creates a foundation for more sophisticated control over the system
-preferences for execution of recipes (for example, see
-:ref:`proposal-effective-job-priorities`).
-
-
-Recipe set execution
-~~~~~~~~~~~~~~~~~~~~
-
-Regardless of the scheduling event that triggers it:
-
-* Whenever a recipe is moved to ``scheduled``, if all other recipes in
- that recipe set are also ``scheduled``, then provisioning of the
- allocated systems and execution of tasks in those recipes will begin.
-
-* As with the current scheduler, the bootloader configuration for guest
- recipes will be set up on the TFTP server at the same time as the
- configuration for the host recipe.
-
-* When running a recipe, a new transient state ``installing`` (between
- ``waiting`` and ``running``) will be used to explicitly track the time
- spent at the start of the recipe provisioning the system for use.
-
-* Whenever a recipe is moved to ``scheduled``, the associated system is
- also moved to ``scheduled``. As the recipe moves through ``waiting``,
- ``installing`` and ``running``, the associated system is moved through
- those same states.
-
-
-.. _system-usage-monitoring:
-
-System usage monitoring
-~~~~~~~~~~~~~~~~~~~~~~~
-
-To provide detailed metrics on individual systems, the current "System
-Status Duration" table will be supplemented by a "System Usage" table.
-
-Where the current table only tracks the overall condition of the system
-(Broken, Manual, Automated), the new table will also track the usage within
-each of those states by adding a new entry whenever the system usage or
-the nominal condition change.
diff --git a/dev/proposals/external-tasks.rst b/dev/proposals/external-tasks.rst
deleted file mode 100644
index 834ba97..0000000
--- a/dev/proposals/external-tasks.rst
+++ /dev/null
@@ -1,186 +0,0 @@
-.. _proposal-external-tasks:
-
-External Tasks for Jobs
-=======================
-
-:Author: Bill Peck, Dan Callaghan
-:Status: Implemented
-:Release: `0.16 <https://beaker-project.org/docs/whats-new/release-0.16.html#external-tasks>`__
-
-This document proposes de-coupling recipe tasks in Beaker from the task
-library. It will be possible to specify tasks in a recipe using an external URL
-without any corresponding task in Beaker's task library.
-
-This feature requires support on the harness side for fetching and unpacking
-tasks from arbitrary URLs. This proposal does not cover updating Beah to
-support external tasks. In this initial iteration, external tasks will only be
-usable with alternative harnesses.
-
-Background and rationale
-------------------------
-
-The ability to run tasks directly from source control or other arbitrary URLs
-has been a long-standing feature request in Beaker. It addresses the
-shortcomings of the centralized, linear, forwards-only versioning model of the
-task library, by allowing users to:
-
-* test individual forks, feature branches, or development versions of a task
- without affecting other users of the same task
-* run an exact revision of a task, for reproducing previous results or testing
- older versions
-* devise their own branching strategy for their tasks (for example, maintaining
- separate branches for different distro families)
-
-An expanded recipe-task model
------------------------------
-
-Currently each "recipe-task" in Beaker must have a correspondingly named entry
-in the task library. Beaker stores the recipe-task as a reference to the task
-library record.
-
-The database schema will be altered so that:
-
-* the relationship from recipe-task to the task library is optional
-* each recipe-task stores the name of the task that is to be run
-* each recipe-task can optionally store the version of the task that was run
-* each recipe-task can optionally have an associated "fetch URL" where the task
- source code is fetched from
-
-The harness API will be extended to allow harness implementations to report the
-name and version of a task back to Beaker.
-
-Specifying name and fetch URL for recipe-tasks
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-It is important that a recipe-task always have a sensible name, so that recipe
-results can be meaningfully displayed even before the recipe starts. This will
-also avoid backwards compatibility issues with external tools expecting every
-recipe-task to have a proper task name. Therefore, when a new recipe is
-submitted Beaker will use the following rules to determine the name of each
-recipe-task.
-
-If the submitted XML only specifies a name for the task, the task must exist in
-Beaker's task library. The recipe-task name is set to the given name. This
-represents no change from the current Beaker behaviour and preserves
-compatibility for harness implementations.
-
-::
-
- <task name="/distribution/reservesys" />
-
-If the submitted XML specifies both a name and a fetch URL, the task need not
-exist in Beaker's task library. The recipe-task name is set to the given name,
-the fetch URL is set to the given URL, and the recipe-task is not associated
-with any task library entry (even if the name matches a task library entry).
-
-Beaker will treat the fetch URL as an opaque string and does not attempt to
-validate or fetch it. The details of how to fetch, unpack, and run the task are
-left up to the harness implementation.
-
-::
-
- <task name="/distribution/reservesys">
- <fetch url="git://example.com/tasks/reservesys#master" />
- </task>
-
-If a fetch URL is specified, a subdirectory may also be specified. This is for
-cases where the fetch URL points at an archive or source repository which
-contains multiple tasks. The subdirectory indicates to the harness where it
-should look to find the task to run. This is represented as a separate
-attribute in the XML, because URLs do not have a standard mechanism to express
-paths within an archive or repository.
-
-::
-
- <task name="/distribution/reservesys">
- <fetch url="git://git.beaker-project.org/beaker-core-tasks#master"
- subdir="reservesys" />
- </task>
-
-The ``name=""`` attribute may be omitted if a fetch URL is specified. In this
-case there is no associated task library entry. Initially Beaker will set the
-recipe-task name to the value of the fetch URL combined with the subdirectory,
-so that it has a distinct and meaningful value by default, but it is expected
-that the harness will later update the recipe-task name to some "prettier"
-value (for example, by extracting the name from :file:`testinfo.desc`).
-
-::
-
- <task>
- <fetch url="git://git.beaker-project.org/beaker-core-tasks#master"
- subdir="reservesys" />
- </task>
-
-Fetch URLs in recipe XML
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-When a recipe-task is associated with a task library entry (no fetch URL), the
-recipe XML served by Beaker will include an ``<rpm/>`` element with the details
-of the RPM from the task library. The harness should install the named RPM
-using the system package installer. This represents no change from the current
-Beaker behaviour and preserves compatibility for harness implementations.
-
-::
-
- <task name="/distribution/reservesys">
- <rpm name="beaker-core-tasks-distribution-reservesys"
- path="/mnt/tests/distribution/reservesys" />
- ...
- </task>
-
-When a recipe-task has a fetch URL, the recipe XML served by Beaker will
-instead contain a ``<fetch/>`` element, matching the submitted job XML::
-
- <task name="/distribution/reservesys">
- <fetch url="git://git.beaker-project.org/beaker-core-tasks#master"
- subdir="reservesys" />
- ...
- </task>
-
-Version for recipe-tasks
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-For recipe-tasks which have an entry in the task library, Beaker will copy the
-current version from the task library to the recipe-task when the recipe is
-Scheduled (this is the point at which the task library snapshot is generated).
-This is the version of the task which should be run (if all goes well).
-
-For recipe-tasks with a fetch URL, the version will be initially empty. Harness
-implementations can update Beaker with the version of the task which was run.
-This is particularly important when fetching from source control. For example,
-a harness implementation might set the version to ``<branch>@<sha>`` for a task
-fetched from git.
-
-Beaker will treat the version as an opaque string. The format of the version
-string is left up to the harness implementation.
-
-The versions will be displayed with the recipe results in Beaker's web UI and
-included in the job results XML.
-
-Harness API
------------
-
-The following new HTTP resource will be available on the lab controller.
-Harness implementations can use this to update the name and version of
-a recipe-task.
-
-.. http:patch:: /recipes/(recipe_id)/tasks/(task_id)
-
- Updates the recipe-task. Accepts JSON :mimetype:`application/json` or
- :mimetype:`application/x-www-form-urlencoded` with the following
- keys/parameters: *name*, *version*, *status*, *message*.
-
-Deferred features
------------------
-
-This proposal does not provide any mechanism for fetching tasks from source
-control with the current version of Beah. If a recipe uses external tasks, it
-must also use a suitable harness implementation. In future it may be possible
-to implement task fetching in Beah itself, or to supply a shim task which can
-handle task fetching when executed by Beah.
-
-In a future release the recipe-task schema could be extended further, to make
-a copy of the RPM name and version when the recipe's task library snapshot is
-created. This would fix two outstanding bugs caused by inconsistencies between
-the Beaker database and the task library snapshot: :issue:`1040258` and
-:issue:`1044934`.
diff --git a/dev/proposals/handling-large-installations.rst b/dev/proposals/handling-large-installations.rst
deleted file mode 100644
index 5b9f192..0000000
--- a/dev/proposals/handling-large-installations.rst
+++ /dev/null
@@ -1,211 +0,0 @@
-.. _proposal-handling-large-installations:
-
-Improved Handling of Large Beaker Installations
-===============================================
-
-:Author: Nick Coghlan
-:Status: In Progress
-
-Abstract
---------
-
-Beaker currently uses a very simple trust model, where systems are
-either "shared" (no group restrictions on use) or "private" (only
-members of specified groups are able to access the system for any
-purpose). Furthermore, making changes to group membership requires
-action by the administrators of the Beaker installation.
-
-The general theme of this design proposal will be to document
-a progressive set of smaller changes, each useful in its own right,
-that combine in later releases to offer a rich policy administration
-capability that allows system owners to prioritise access to their own
-hardware.
-
-The intent is that, by the time this proposal is implemented, owners
-of systems in Beaker should be comfortable making their systems available
-for use by other users of the same Beaker installation, while being
-confident that they remain in full control of the usage policies for those
-systems, including whether or not other users are even aware of the
-system's presence.
-
-This is a living document that will be updated over the course of
-Beaker's development.
-
-Refer to :ref:`dev-lifecycle` for more information on the Beaker development
-process.
-
-
-Beaker 0.12
------------
-
-Release date: 5th April, 2013
-
-Beaker 0.12 made it easier for users to switch between production and
-development Beaker instances. It has three key elements:
-
-* A new script was added to the Beaker server tools, which allows a
- system administrator to update the task library from the task
- library of another Beaker instance
-* The Beaker client gained a new ``--hub`` parameter which makes it easy
- to run a command against a Beaker instance other than the one in
- the system or user configuration file.
-* The Beaker client configuration architecture was adjusted to make it
- easy to provide a system wide site specific configuration file, rather
- than requiring each user to define their own configuration
-
-See the `Beaker 0.12 Release Notes <../../docs/whats-new/#beaker-0-12>`__ for
-details.
-
-
-Beaker 0.13
------------
-
-Release date: 7th June, 2013
-
-The focus of Beaker 0.13 was :ref:`proposal-enhanced-user-groups`
-
-The elements of the proposal implemented in this release included three key
-elements:
-
-* Administrators may delegate membership of specific groups to an
- LDAP server (to avoid maintaining membership data in two locations)
-* Users may create and manage their own custom groups (to avoid overloading
- the administrators of large installations)
-* Jobs may be submitted on behalf of a group, granting all members of that
- group full access to the job (to avoid the creation of shared accounts
- for collective management of jobs)
-
-See the `Beaker 0.13 Release Notes <../../docs/whats-new/#beaker-0-13>`__ for
-details.
-
-
-Beaker 0.14
------------
-
-Release date: 2nd August, 2013
-
-The focus of Beaker 0.14 development was the completion of
-:ref:`proposal-enhanced-user-groups`, by allowing users to nominate
-"submission delegates" that can submit jobs on their behalf.
-
-See the `Beaker 0.14 Release Notes
-<../../docs-release-0.14/whats-new/#beaker-0-14>`__ for details.
-
-Due to the issues with the initial Beaker 0.15 update, Beaker 0.14
-received an extended maintenance life cycle (through to December 2013).
-
-
-Beaker 0.15
------------
-
-Release date: 22 October 2013 (for 0.15.1)
-
-The focus of Beaker 0.15 was the per-system access policy portion of
-:ref:`proposal-access-policies`.
-
-Just as the enhanced user group model allowed groups to assume shared
-management of jobs, the new access policy model allows groups to
-assume shared management of systems.
-
-See the `Beaker 0.15 Release Notes
-<../../docs-release-0.15/whats-new/#beaker-0-15>`__ for details.
-
-Note that the initial release of Beaker 0.15 including a number of critical
-defects in the revised permissions model and the upgraded web interface that
-rendered it effectively undeployable. The release date given above is for the
-0.15.1 maintenance release that addressed these critical issues.
-
-Due to the extended maintenance lifecycle for Beaker 0.14, Beaker 0.15 also
-has an extended maintenance life cycle (through to February 2014).
-
-
-Beaker 0.16
------------
-
-Release date: 14 March 2014
-
-The focus of Beaker 0.16 was the :ref:`proposal-external-tasks` design
-proposal, allowing tasks to be managed as references to external git
-repositories, rather than forcing reliance on Beaker's centralised library of
-task RPMs.
-
-In addition to the significant benefits this offers in task management
-itself (such as more exact reproducability of previous test runs, easier
-testing of experimental versions of tasks and more flexibility in test
-structure), this proposal also has the benefit of avoiding the need to
-frequently regenerate yum repo metadata for a central task library that may
-end up containing thousands of tasks.
-
-See the `Beaker 0.16 Release Notes
-<../../docs-release-0.16/whats-new/#beaker-0-16>`__ for details.
-
-
-Beaker 0.17
------------
-
-Release date: 11th June, 2014
-
-Beaker 0.17 included two new scheduler features:
-
-* A test harness independent system reservation mechanism via the
- ``<reservesys/>`` Job XML element. This makes it possible to debug
- issues during test execution which may have caused the external
- watchdog to expire, a kernel panic or an installation failure.
-
-* Force schedule a job on a system irrespective of its status. This
- makes it possible to run diagnostic tests on broken or manual
- systems before adding them back to the pool of available systems.
-
-In addition, it included experimental integration with OpenStack for
-dynamically creating VMs (additional background available in the
-:ref:`proposal-dynamic-virtualization` design proposal).
-
-See the `Beaker 0.17 Release Notes
-<../../docs-release-0.17/whats-new/#beaker-0-17>`__ for details.
-
-
-Beaker 0.18
------------
-
-Release date: 4th September, 2014
-
-Beaker 0.18 included improved usage reminder emails as described in
-the :ref:`proposal-beaker-usage-report-emails` design propsal and
-introduced better support for custom distros (as described in the
-:ref:`custom-distros` design proposal).
-
-See the `Beaker 0.18 Release Notes
-<../../docs-release-0.18/whats-new/#beaker-0-18>`__ for details.
-
-Beaker 19 (tentative)
----------------------
-
-Planned Release date: October, 2014
-
-The tentative focus of Beaker 19 is to implement an improved system
-details page in the Beaker web UI, as the Beaker 0.15 release not only
-highlighted many of the shortcomings of the existing interface, but also
-provided greatly improved tools for dealing with them.
-
-Refer to :ref:`proposal-system-page-improvements` for details.
-
-
-Future Beaker releases
-----------------------
-
-The following design proposals, or functional equivalents, are expected to be
-implemented across several additional releases and should all
-contribute to improve Beaker's usefulness in large installations:
-
-* :ref:`proposal-time-limited-manual-reservations`
-* :ref:`proposal-time-limited-system-loans`
-* the "Predefined Access Policies" portion of :ref:`proposal-access-policies`
-* :ref:`proposal-event-driven-scheduling`
-* :ref:`proposal-system-pools`
-* :ref:`proposal-effective-job-priorities`
-
-With all of these proposals implemented, Beaker will provide system owners
-with comprehensive and flexible control over their systems, allowing them
-to make them readily available to other users, while still ensuring they
-can access the system when they need to (including prioritising their own
-jobs, or those of their team, over jobs submitted by other users).
diff --git a/dev/proposals/harness-api.rst b/dev/proposals/harness-api.rst
deleted file mode 100644
index 2990a86..0000000
--- a/dev/proposals/harness-api.rst
+++ /dev/null
@@ -1,321 +0,0 @@
-
-.. _harness-api:
-
-Stable Harness API
-==================
-
-:Author: Dan Callaghan
-:Status: Implemented (with minor modifications)
-:Release: `0.12 <http://beaker-project.org/docs/whats-new/release-0.12.html#provisional-support-for-alternative-harnesses>`__
-
-Beah, the Beaker harness, currently uses XML-RPC methods exposed by
-beaker-proxy to communicate with Beaker. This API has evolved organically, in
-lock-step with Beah itself, and was derived in part from older APIs in RHTS. In
-some cases it is awkward to use. It has never been documented and is not
-considered a public or stable interface by the Beaker developers.
-
-As a first step toward supporting alternative harnesses in Beaker, it is
-recognised that a stable, documented harness API is needed. This proposal is
-for a new harness API which covers roughly the same functionality as the
-existing XML-RPC API, but with a cleaner design. Developers who are working on
-integrating other harnesses with Beaker will be encouraged to use this new API.
-The existing XML-RPC API will remain as an internal-only implementation detail.
-
-The existing XML-RPC API provides the following functionality to the harness:
-
-* fetching recipe details
-* fetching task details
-* extending the watchdog
-* marking tasks as running or completed
-* recording results
-* uploading logs
-
-The new API covers the same areas. It also covers how Beaker configures the
-harness.
-
-Environment variables
----------------------
-
-Beaker will configure the following system-wide environment variables. When
-installed, a harness implementation must arrange to start itself on reboot and
-then configure itself according to these values.
-
-``BEAKER_LAB_CONTROLLER_URL``
- Base URL of the Beaker lab controller. The harness communicates with Beaker
- by accessing HTTP resources (described below) underneath this URL.
-
-``BEAKER_LAB_CONTROLLER``
- The fully-qualified domain name of the lab controller to which this system
- is attached. This will always match the hostname portion of
- ``BEAKER_LAB_CONTROLLER_URL`` but is provided for convenience.
-
-``BEAKER_RECIPE_ID``
- The ID of the Beaker recipe which this system is currently running. Use
- this to fetch the recipe details from the lab controller as described
- below.
-
-``BEAKER_HUB_URL``
- Base URL of the Beaker server. Note that the harness should not communicate
- with the server directly, but it may need to pass this value on to tasks.
-
-HTTP resources
---------------
-
-The lab controller exposes the following HTTP resources for use by the harness.
-All URL paths given below are relative to the value of the
-``BEAKER_LAB_CONTROLLER_URL`` environment variable.
-
-When using the :http:method:`POST` method with the resources described below,
-the request body must be given as HTML form data
-(:mimetype:`application/x-www-form-urlencoded`).
-
-.. http:get:: /recipes/(recipe_id)/
-
- Returns recipe details. Response is in Beaker job results XML format, with
- :mimetype:`application/xml` content type.
-
-.. http:post:: /recipes/(recipe_id)/watchdog
-
- Extends the watchdog for a recipe.
-
- :form seconds: The watchdog kill time is updated to be this many seconds
- from now.
- :status 204: The watchdog was updated.
-
-.. http:post:: /recipes/(recipe_id)/status
-
- Updates the status of all tasks which are not already finished.
-
- :form status: The new status. Must be *Completed* or *Aborted*.
- :status 204: The task status was updated.
- :status 400: Bad parameters given.
-
- Typically the harness will update the status of each task individually as it
- runs (see below). This is provided as a convenience only, for example to
- abort all tasks in a recipe.
-
-.. http:post:: /recipes/(recipe_id)/tasks/(task_id)/status
-
- Updates the status of a task.
-
- :form status: The new status. Must be *Running*, *Completed*, or *Aborted*.
- :status 204: The task status was updated.
- :status 400: Bad parameters given.
- :status 409: Requested state transition is invalid.
-
- Tasks in Beaker always start out having the *New* status. Once a task is
- *Running*, its status may only change to *Completed*, meaning that the task
- has completed execution, or *Aborted*, meaning that the task's execution did
- not complete (or never began) because of some unexpected condition. Once
- a task is *Completed* or *Aborted* its status may not be changed. Attempting
- to change the status in a way that violates these rules will result in
- a :http:statuscode:`409` response.
-
-.. http:post:: /recipes/(recipe_id)/tasks/(task_id)/results/
-
- Records a task result. Returns a :http:statuscode:`201` response with a
- :mailheader:`Location` header in the form
- ``/recipes/(recipe_id)/tasks/(task_id)/results/(result_id)``.
-
- :form result: The result. Must be *Pass*, *Warn*, *Fail*, or *None*.
- :form path: Path of the result. Conventionally the top-level result will be
- recorded as ``$TEST``, with sub-results as ``$TEST/suffix``, but this
- is not required. If not specified, the default is ``/``.
- :form score: Integer score for this result. The meaning of the score is
- defined on a per-task basis, Beaker intentionally enforces no meaning.
- If not specified, the default is zero.
- :form message: Textual message to accompany the result. This is typically
- short, and is expected to be displayed in one line in Beaker's web UI.
- Use the log uploading mechanism to record test output.
- :status 201: New result recorded.
- :status 400: Bad parameters given.
-
-.. http:put::
- /recipes/(recipe_id)/logs/(path:path)
- /recipes/(recipe_id)/tasks/(task_id)/logs/(path:path)
- /recipes/(recipe_id)/tasks/(task_id)/results/(result_id)/logs/(path:path)
-
- Stores a log file.
-
- :status 204: The log file was updated.
-
- Use the :mailheader:`Content-Range` header to upload part of a file.
-
-.. http:get::
- /recipes/(recipe_id)/logs/(path:path)
- /recipes/(recipe_id)/tasks/(task_id)/logs/(path:path)
- /recipes/(recipe_id)/tasks/(task_id)/results/(result_id)/logs/(path:path)
-
- Returns an uploaded log file.
-
- Use the :mailheader:`Range` header to request part of a file.
-
-.. http:get::
- /recipes/(recipe_id)/logs/
- /recipes/(recipe_id)/tasks/(task_id)/logs/
- /recipes/(recipe_id)/tasks/(task_id)/results/(result_id)/logs/
-
- Returns a listing of all uploaded logs.
-
- Possible response formats include an HTML index (:mimetype:`text/html`) or
- an Atom feed (:mimetype:`application/atom+xml`). Use the
- :mailheader:`Accept` header to request a particular representation. The
- default is HTML.
-
-Provisional period for the API
-------------------------------
-
-Before we commit to preserving a stable interface essentially forever, we need
-to have some confidence that the interface is useful and convenient for harness
-implementations to use. The best way to validate the interface is to build (or
-encourage others to build) harness implementations which use it.
-
-Therefore, in its initial release the harness API will be considered
-"provisional" (and documented as such). In future releases we might make minor
-changes, removals, or additions in order to make the API more convenient for
-harness implementations, depending on feedback received after the initial
-release.
-
-Once the API has been validated, it will be declared "stable" and no further
-backwards-incompatible changes will be made to it.
-
-.. _user-defined-harness:
-
-User-defined harness per recipe
--------------------------------
-
-Part of the stable interface is standardizing how Beaker configures the
-harness. With this in place, we can add a simple way for users to select an
-alternative harness on a per-recipe basis.
-
-A new kickstart metadata variable, ``harness``, will be defined. Its default
-value is ``beah``. When set to ``beah``, the existing kickstart template logic
-for configuring ``/etc/beah_beaker.conf`` and installing Beah is used. When set
-to any other value, Beah-specific parts of the template are skipped. Instead,
-the kickstart will contain a command to install the named harness.
-
-This means the default behaviour is unchanged. If a user wants to use an
-alternate harness they can configure their job XML as desired, for example::
-
- <recipe ks_meta="harness=mylittleharness">
- <repos>
- <repo name="mylittleharness"
- url="http://example.com/mylittleharness/el6/" />
- </repos>
- ...
- </recipe>
-
-The generated kickstart for this recipe will contain the following line in
-a ``%post`` section::
-
- yum -y install mylittleharness
-
-which will cause the mylittleharness package to be installed from the user's
-custom yum repo.
-
-The value of the ``harness`` variable will be substituted directly into the
-``yum install`` command line. Note that this means the ``harness`` variable may
-contain any valid package specification accepted by yum, including one or more
-package names or absolute package URLs.
-
-Rejected features
------------------
-
-The following ideas were brought up during discussions of this proposal, but
-they will not be implemented for the reasons given.
-
-Adding tasks to a running recipe
-++++++++++++++++++++++++++++++++
-
-There is no mechanism for the harness to add tasks to an existing recipe.
-A recipe is an immutable sequence of one or more tasks for the harness to
-execute. A cloned recipe should produce the same execution as its
-original recipe, but this would be violated if the harness has added extra
-tasks.
-
-In addition, adding tasks to an existing recipe introduces the possibility that
-the recipe's state could go backwards, from Completed to Running. This would
-violate an invariant which is relied on by a lot of code in Beaker, and by its
-users.
-
-The recommended way for the harness to deal with the situation where a single
-task (from Beaker's point of view) actually contains many "sub-tasks" (from the
-harness' point of view) is to report multiple results for the task, each under
-a different path.
-
-Deferred features
------------------
-
-The following ideas were brought up during discussions of this proposal, but
-they will not be addressed by this first provisional version of the API.
-
-Harness configuration per recipe
-++++++++++++++++++++++++++++++++
-
-Currently the harness is configured in two ways: Beaker passes configuration
-through system-wide environment variables, as described above; and tasks
-provide metadata to the harness, such as their expected runtime and desired
-environment (``testinfo.desc`` for RHTS-format tasks). However, there is no
-mechanism to override this configuration from the job XML.
-
-It is desirable to allow users to pass arbitrary harness-specific configuration
-from their job XML, either globally at the recipe level, or at the individual
-task level.
-
-One possibility is to allow the job XML to override or extend the task metadata
-for a given task, by using the same fields as in ``testinfo.desc``. However,
-it's not clear how this could be represented in XML, nor how it would extend to
-harnesses/tasks which don't use the RHTS-like ``testinfo.desc`` metadata.
-
-Complete representations for every resource
-+++++++++++++++++++++++++++++++++++++++++++
-
-By convention, all of the HTTP resources described above should also allow GET
-requests, returning some useful representation. However, designing future-proof
-response formats for all those resources is not trivial, so they are not
-included in this proposal. The monolithic results XML (as returned by
-:http:get:`/recipes/(recipe_id)/`) may not be the most ideal format, but it
-does include all information about a recipe (except for logs) and has the
-advantage of being well-established in Beaker.
-
-Once these future response formats have been designed, they can also be used
-for requests instead of the simple form encoding as defined in this proposal.
-
-Aborting an entire recipe set or job
-++++++++++++++++++++++++++++++++++++
-
-The XML-RPC API includes methods for the harness to abort an entire recipe set
-(``recipeset_stop``) or job (``job_stop``), but there is no equivalent
-functionality defined in this API. It is not clear that this capability is
-useful or desirable. An alternative is to offer the job submitter control over
-what kinds of failures result in aborting all or parts of the job (see for
-example `Nick Coghlan's suggestions
-<http://thread.gmane.org/gmane.comp.systems.beaker.devel/451/focus=479>`_).
-
-Harness check-in
-++++++++++++++++
-
-As harness implementations proliferate, it may be useful to encourage harnesses
-to report their name, version, and configuration to Beaker as a "harness
-check-in" step at the start of the recipe. Beaker can display this information
-to users, to make it clear which harness implementation ran their recipe.
-
-In future a check-in step may be formalised as part of this API, but for now
-harnesses are encouraged to report these details as a recipe log with
-a consistent and obvious name (for example, ``harness-checkin.log``).
-
-Storing results and logs in external systems
-++++++++++++++++++++++++++++++++++++++++++++
-
-The are no plans to integrate Beaker itself with any specific tool for managing
-test runs and results. But a harness implementation may choose to report its
-results to an external tool in addition to (or instead of) reporting results to
-Beaker. In this case it would be useful for the Beaker results to contain
-a reference to the corresponding results in the external tool.
-
-One possibility is to allow "remote" logs -- that is, logs registered in Beaker
-but stored elsewhere. Beaker would record only the remote URL associated with
-the log.
-
-Another possibility is to allow an optional URL to be associated with each
-result, which is presented as a hyperlink in Beaker's web UI.
diff --git a/dev/proposals/index.rst b/dev/proposals/index.rst
deleted file mode 100644
index 93acce1..0000000
--- a/dev/proposals/index.rst
+++ /dev/null
@@ -1,106 +0,0 @@
-.. _design-proposals:
-
-Design proposals
-----------------
-
-Beaker design proposals are used for major changes that require more upfront
-discussion and design than can be suitably handled in a single Bugzilla
-entry or Gerrit patch review.
-
-Each design proposal must include a rationale for making the change, and
-should provide sufficient detail of the desired solution that it can be
-used to gain meaningful feedback from other developers or Beaker users.
-
-Rather than approving designs as a whole, specific elements of the design are ultimately approved through the normal review processes in Bugzilla and
-Gerrit. It is expected that some of the details in design proposals may
-change as implementation reveals additional aspects that were not previously considered.
-
-Design proposals under consideration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These are design proposals currently under consideration for incorporation
-into a future version of Beaker.
-
-.. Rather than assigning numbers, new design proposals should just be
- created as files in this subdir and appended to this TOC.
- Proposals will be referred to by their title or URL rather than by a
- number (this is similar to Fedora feature names)
-
-* There are currently no completely new design proposals under consideration
-
-.. toctree::
- :maxdepth: 1
-
-.. note::
-
- Not all changes require an associated design proposal. Some changes,
- (such as those for the Beaker build process and website, or Fedora
- compatibility fixes) are handled directly in Gerrit. Most other changes
- are tracked as Bugzilla entries. A design proposal is appropriate if a
- change touches several different parts of Beaker, or if it is a
- user visible piece of functionality where the overall design should
- be discussed with Beaker users *before* significant effort is expended
- on the implementation.
-
-
-In progress design proposals
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These are design proposals that are currently in progress, with at least
-some features available in a released version of Beaker (or a related
-project), or else under active development for an upcoming Beaker release.
-
-.. toctree::
- :maxdepth: 1
-
- handling-large-installations
- reference-harness
- system-page-improvements
- inventory-lshw-migration
-
-
-Deferred design proposals
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These are design proposals that have been deferred pending further research
-into alternative options, or else have had their priority reassessed based
-on other changes.
-
-.. toctree::
- :maxdepth: 1
-
- access-policies-for-systems
- system-pools
- event-driven-scheduler
- effective-job-priorities
- time-limited-manual-reservations
- time-limited-system-loans
-
-
-Completed design proposals
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These are design proposals that have been incorporated into a released
-version of Beaker.
-
-.. toctree::
- :maxdepth: 1
-
- harness-api
- enhanced-user-groups
- external-tasks
- beaker-usage-report-emails
- custom-distros
- dynamic-virtualization
-
-
-Rejected/withdrawn design proposals
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These are design proposals that have been determined to be outside Beaker's
-scope, or are otherwise considered a poor fit for the system.
-
-* There are currently no previously rejected/withdrawn design proposals
-
-.. toctree::
- :maxdepth: 1
diff --git a/dev/proposals/inventory-lshw-migration.rst b/dev/proposals/inventory-lshw-migration.rst
deleted file mode 100644
index 45dee77..0000000
--- a/dev/proposals/inventory-lshw-migration.rst
+++ /dev/null
@@ -1,119 +0,0 @@
-.. _proposal-lshw-migration:
-
-Migrating to lshw for inventory task
-====================================
-
-:Author: Amit Saha
-:Status: In Progress
-:Target Release: TBD
-
-Abstract
---------
-
-This proposal outlines the plan of action to replace the current
-:program:`smolt` based inventory task by one which uses
-:program:`lshw`.
-
-
-Dependencies
-------------
-
-None.
-
-
-Proposal
---------
-
-Currently, Beaker's inventory task uses smolt (besides reading
-directly from the procfs file system) to gather the details of various
-hardware devices on a system. Due to the `retirement announcement
-<https://fedoraproject.org/wiki/Smolt_retirement>`__ of smolt, this
-will make it impossible to run the inventory task on current and
-future releases of Red Hat Enterprise Linux and Fedora. Users have
-also reported smolt's ineffectiveness in certain cases (see bug
-report: :issue:`541294`). On the other hand, `lshw
-<http://ezix.org/project/wiki/HardwareLiSter>`__ is actively
-maintained and is thus a future-proof alternative for Beaker's
-inventory task. For this migration to be successful without affecting
-the utility of the inventory task, a number of aspects need to be
-looked into. These are described in the rest of this proposal.
-
-Implementation of the inventory task
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Currently, Beaker's inventory task performs both the functions of
-retrieving the hardware data and sending it to the Beaker server. This
-makes the retrieval part of the process tightly coupled to the inventory
-task (running as part of a Beaker job). However, it is not necessary that
-inventory will always be performed on a system as part of a job and should not be
-so.
-
-A new utility :program:`beaker-system-scan` has been created
-which is capable of retrieving and sending the retrieved hardware data
-to a Beaker server. This utility was created by "extracting out" the
-relevant programs from the current inventory task. Beaker's inventory
-task's functionality is thus reduced to invoking beaker-system-scan.
-
-The use of smolt in beaker-system-scan will be replaced by lshw.
-
-Enhancing lshw and upstream contributions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-It has been found that lshw retrieves incomplete
-information on architectures such as IBM s390x and ARM. For example,
-it lacks any support for retrieving the CPU information on IBM
-s390x. Thus, existing features of lshw will need
-enhancement to work correctly on such architectures. On the other
-hand, lshw doesn't retrieve information such as audio codecs, which is
-an example of a feature that we need to add to lshw to suit Beaker's needs.
-
-Enhancements to lshw will first be incorporated into Beaker project's
-fork of `lshw <http://git.beaker-project.org/cgit/lshw/>`__ and then
-pull requests sent to the `upstream repository
-<https://github.com/lyonel/lshw>`__ via GitHub.
-
-The major enhancements merged to the fork so far are:
-
-- A "chroot" based testing framework. This is described briefly in the
- next section.
-
-- Better support for retrieving CPU information on ARM and s390x systems.
-
-Maintaining a fork of lshw is motivated by two factors:
-
-- Allow beaker-system-scan to be updated independently of the upstream
- lshw release cycle
-
-- Allow sufficient testing of the changes and then submit requests for
- integration into upstream
-
-Test suite development for lshw
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The chroot based testing framework runs lshw in a chroot so that
-instead of reading files from /proc and /sys on the
-system, they read the test data files made available in the chroot.
-
-Although this doesn't allow testing data which are retrieved by
-lshw using system calls, it allows a basic level of sanity
-testing to make sure regressions are caught.
-
-
-Comparing the data obtained from smolt and lshw
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Once lshw's features have been expanded and extended to suit Beaker's
-needs, a thorough comparison of the data retrieved from smolt and lshw
-is required to see if lshw is able to get all the data that
-smolt would give us. If not, either lshw should be enhanced to
-retrieve those data or if the data is not important to Beaker's users,
-document it as such.
-
-Related tasks
-~~~~~~~~~~~~~
-
-beaker-system-scan currently uses :command:`hal-find-by-property` and
-:command:`hal-get-property` to retrieve storage controller
-details and libparted to retrieve details of disk drives.
-In both the cases, lshw will be used instead (See :issue:`896302` and
-:issue:`902567` for details).
diff --git a/dev/proposals/reference-harness.rst b/dev/proposals/reference-harness.rst
deleted file mode 100644
index 0fb27a8..0000000
--- a/dev/proposals/reference-harness.rst
+++ /dev/null
@@ -1,88 +0,0 @@
-Reference Harness
-=================
-
-:Author: Dan Callaghan
-:Status: In Progress
-:Target Release: TBD
-
-This proposal is for a "reference harness" implementation to be developed for
-Beaker. The purpose of the reference harness is to validate the proposed
-:ref:`harness API <harness-api>`, and to prototype some of the more radical
-harness features which have been proposed previously under the mantle of
-"Beaker Simple Harness":
-
-* Fetching tasks directly from source control or elsewhere (bypassing the
- Beaker task library)
-* No external dependencies
-* Portability to older distros and non-Linux platforms
-* IPv6 support (including dual-stack and IPv6-only)
-* Clean, complete execution environment for tasks
-* Installing task dependencies at the start of the task, instead of relying on
- Anaconda ``%packages``
-
-Explicit *non*-goals:
-
-* 100% compatibility with Beah (RHTS)
-* RHTS XML-RPC emulation
-* Support for multi-host synchronization
-
-As suggested by its name, the reference harness will also provide a starting
-point for others who want to develop their own harness, or want to expand the
-reference harness to meet their needs. In future the reference harness code may
-evolve into a STAF "service", a shim or wrapper layer or library for STAF and
-other harnesses, a complete replacement for Beah, or any of the above.
-
-The reference harness will be a separate source tree from Beaker, and its
-release cycle will not (necessarily) be tied to Beaker releases. The
-user-defined harness support in Beaker will allow multiple versions of the
-reference harness to be used at any time, without interfering with Beaker
-itself.
-
-Implementation language
------------------------
-
-The reference harness will be implemented in C, using mature, proven,
-cross-platform libraries where appropriate (for example, `glib`_, `libcurl`_,
-`libarchive`_).
-
-By default the build will dynamically link against system libraries (making it
-acceptable for inclusion in Fedora), but it will also support statically
-linking against bundled versions of all dependencies except for the system
-libc. In this way it will be possible to use modern versions of utility
-libraries even on older distros and platforms, without introducing extra
-runtime dependencies.
-
-Why not Python? Beah is written in Python, as are all known alternative harness
-implementations, and of course so is Beaker itself.
-
-However, the harness needs to support Red Hat Enterprise Linux 3 where the
-system Python interpreter is version 2.2. Not only is it awkward to write code
-for such an old Python version, but no modern Python libraries support Python
-2.2. So the two alternatives are to ship an entire updated Python stack for
-RHEL3 (as Beah does), or to make the harness implementation compatible back to
-Python 2.2 without using any external libraries. Static linking is a good
-solution to this problem, because it lets us use modern versions of external
-libraries without introducing extra dependencies at runtime.
-
-Static linking will also help on modern platforms, where users want to
-provision their recipe with a minimal package set and don't want the harness to
-"infect" it with additional packages which wouldn't normally be installed.
-
-The job of the harness is also by its nature quite low-level and in some cases
-(for example, tty handling) may require calling platform libraries which are
-not exposed in Python.
-
-Additionally, this will help to minimize the CPU, memory, and disk footprint of
-the harness.
-
-.. _glib: http://developer.gnome.org/glib/
-.. _libcurl: http://curl.haxx.se/libcurl/
-.. _libarchive: http://www.libarchive.org/
-
-
-Current status
---------------
-
-The initial version of the reference harness was created by Dan Callaghan,
-and is now being further developed by Bill Peck on
-`GitHub <https://github.com/p3ck/restraint/>`__.
diff --git a/dev/proposals/system-page-improvements-screenshots/details-tab.png b/dev/proposals/system-page-improvements-screenshots/details-tab.png
deleted file mode 100644
index ad03bf1..0000000
--- a/dev/proposals/system-page-improvements-screenshots/details-tab.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/essentials-tab.png b/dev/proposals/system-page-improvements-screenshots/essentials-tab.png
deleted file mode 100644
index 6a120cf..0000000
--- a/dev/proposals/system-page-improvements-screenshots/essentials-tab.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/lend-modal.png b/dev/proposals/system-page-improvements-screenshots/lend-modal.png
deleted file mode 100644
index 8aab516..0000000
--- a/dev/proposals/system-page-improvements-screenshots/lend-modal.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/loan-tab.png b/dev/proposals/system-page-improvements-screenshots/loan-tab.png
deleted file mode 100644
index 7d1ea2c..0000000
--- a/dev/proposals/system-page-improvements-screenshots/loan-tab.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/owner-tab.png b/dev/proposals/system-page-improvements-screenshots/owner-tab.png
deleted file mode 100644
index 6ddb937..0000000
--- a/dev/proposals/system-page-improvements-screenshots/owner-tab.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/provision-tab.png b/dev/proposals/system-page-improvements-screenshots/provision-tab.png
deleted file mode 100644
index 1c03699..0000000
--- a/dev/proposals/system-page-improvements-screenshots/provision-tab.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/reserve-workflow.png b/dev/proposals/system-page-improvements-screenshots/reserve-workflow.png
deleted file mode 100644
index 4d120b7..0000000
--- a/dev/proposals/system-page-improvements-screenshots/reserve-workflow.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/scheduler-tab.png b/dev/proposals/system-page-improvements-screenshots/scheduler-tab.png
deleted file mode 100644
index 0b195fd..0000000
--- a/dev/proposals/system-page-improvements-screenshots/scheduler-tab.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements-screenshots/system-page-0.14.png b/dev/proposals/system-page-improvements-screenshots/system-page-0.14.png
deleted file mode 100644
index 923fa0b..0000000
--- a/dev/proposals/system-page-improvements-screenshots/system-page-0.14.png
+++ /dev/null
Binary files differ
diff --git a/dev/proposals/system-page-improvements.rst b/dev/proposals/system-page-improvements.rst
deleted file mode 100644
index bd9f26a..0000000
--- a/dev/proposals/system-page-improvements.rst
+++ /dev/null
@@ -1,313 +0,0 @@
-.. _proposal-system-page-improvements:
-
-System Page Improvements
-========================
-
-:Author: Dan Callaghan
-:Status: In Progress
-:Target Release: 19
-
-This document proposes rearranging the system page to replace the system form
-with three "quick info" boxes. The goal of the quick info boxes is to show the
-most important facts about the system and to give quick access to the most
-common operations, while occupying a very small amount of vertical space. The
-interface elements previously contained in the system form will be grouped in
-tabs below.
-
-Background and rationale
-------------------------
-
-The system form --- the set of fields arranged in two columns at the top of the
-system page --- has existed since Beaker's inception as Medusa, a lab inventory
-tracking system. The system form is the original basis of the page, and has
-always been its focal point. Over the years of Beaker's growth, additional
-functionality has accumulated either in tabs below the system form or as extra
-interface elements cluttered inside the form itself.
-
-As a result, the system form conveys a disorganized assortment of data about
-the system, of which only a small amount is relevant for any given workflow on
-the page.
-
-.. figure:: system-page-improvements-screenshots/system-page-0.14.png
- :width: 100%
- :alt: [screenshot of system page in Beaker 0.14]
-
- An example of the system page in Beaker 0.14.
-
-Due to the more generous form spacing introduced by Bootstrap in Beaker 0.15,
-the system form now occupies even more vertical space than it did before. This
-change only served to highlight how much irrelevant information was being shown
-at the top of the page (see for example bug :issue:`1015100`).
-
-It has also been recognized for a long time that TurboGears 1.x widgets are not
-working for us. We can deliver a smoother, more efficient, and more functional
-experience by using a modern approach where HTML rendering is handled (at least
-partially) on the client side. This approach is only practical since Beaker's
-technology stack was upgraded in version 0.15 to use Flask on the server side
-and Bootstrap for client-side styling.
-
-Mitigating impacts on screen scraping
--------------------------------------
-
-The Beaker developers are aware that users have been forced to rely on scraping
-the system page in the past, due to the poor coverage of Beaker's API for
-systems. Unfortunately the proposed changes to the system page will
-substantially alter the HTML produced by the server, which may impact any
-screen scraping scripts.
-
-During the 0.15.x release series the developers introduced a number of new
-:program:`bkr` subcommands for managing systems. These commands, along with the
-existing system-related subcommands, can be used instead of scraping the system
-page.
-
-* Commands for viewing and manipulating access policies, which replaced
- group-based access control in Beaker 0.15.0: :program:`bkr policy-list`,
- :program:`bkr policy-grant`, :program:`bkr policy-revoke`
-* Commands for manipulating loans, added in Beaker 0.15.2:
- :program:`bkr loan-grant`, :program:`bkr loan-return`
-* A command to fetch the status of a system (its condition, current reservation
- details, and current loan details), added in Beaker 0.15.3: :program:`bkr
- system-status`
-
-UI changes
-----------
-
-This section describes the proposed UI changes in detail.
-
-All new user interface elements described here will use the Backbone JavaScript
-library to coordinate client-side rendering and updates. The client-side
-widgets fetch data from the server in JSON format and make asynchronous calls
-to update the server state without refreshing the page.
-
-Quick info boxes
-++++++++++++++++
-
-There are three quick info boxes, displayed side-by-side at the top of the
-system page. See the screenshots below for an example.
-
-The left-hand quick info box shows a summary of the system's hardware: vendor,
-model, CPU, and memory. It also indicates whether remote power control is
-available. In a future release it could also indicate whether remote console is
-available (currently Beaker does not record this information). The goal of this
-box is to quickly answer the question: "What is this system, and can it do what
-I need?"
-
-The middle quick info box shows a summary of the system's health: current
-condition, condition report (if any), and number of recent aborted recipes. For
-the system owner, this box also contains a quick action button to remove the
-system from service (set its condition to Broken). For other users, it contains
-a button to send a problem report to the owner. The goal of this quick info box
-is to quickly answer the question: "Is this system healthy right now?"
-
-The right-hand quick info box shows a summary of the system's usage: current
-loan, current user, and reservation length. It also contains a quick action
-button which allows one of the following operations, depending on the current
-state of the system and the user's permissions: Take, Return, Borrow, Return
-Loan, Request Loan. The goal of this quick info box is to quickly answer the
-question: "Can I use this system right now?"
-
-Vertical tabs
-+++++++++++++
-
-The number of tabs on the system page has only grown over the years as features
-have been added to the page, and extracting functionality from the system form
-would require adding even more tabs. The horizontal tabs in Beaker 0.14 were
-already wrapping to two lines at many common browser widths. Therefore, the
-tabs were converted to a vertical "nav list" Bootstrap component with the tab
-content displayed beside. (This change was previously not possible using the
-TurboGears 1.x Tabber widget.)
-
-The vertical tabs are visible in the screenshots below.
-
-New :guilabel:`Hardware Essentials` tab
-+++++++++++++++++++++++++++++++++++++++
-
-A new tab, :guilabel:`Hardware Essentials`, contains the following fields which
-previously lived in the system form and held "essential" information about the
-system’s hardware:
-
-* Lab controller
-* Location
-* Lender
-* Kernel type
-
-The tab also contains a field for :guilabel:`Supported Architectures`,
-replacing the :guilabel:`Arches` tab.
-
-Here "essential" means information that the system owner fills in when
-registering the system in Beaker, as opposed to the hardware information on the
-:guilabel:`Hardware Details` tab which describes the internals of the system
-and is populated by Beaker's inventory script.
-
-Beaker users will typically not be interested in the fields on the
-:guilabel:`Hardware Essentials` tab, so the target audience for this tab is
-primarily system owners.
-
-.. figure:: system-page-improvements-screenshots/essentials-tab.png
- :width: 100%
- :alt: [screenshot of proposed Hardware Essentials tab]
-
-Expanded :guilabel:`Hardware Details` tab
-+++++++++++++++++++++++++++++++++++++++++
-
-The following fields from the system form now appear on the :guilabel:`Hardware
-Details` tab instead. These fields describe internal hardware information about
-the system, and can (or should) be populated automatically by Beaker's
-inventory script.
-
-* Host hypervisor
-* Vendor
-* Model
-* Serial number
-* MAC address
-
-In addition, it is now possible to edit hardware details in the
-:guilabel:`System` section (which is the above fields plus the two existing
-:guilabel:`Memory` and :guilabel`NUMA Nodes` fields).
-
-.. figure:: system-page-improvements-screenshots/details-tab.png
- :width: 100%
- :alt: [screenshot of proposed Hardware Details tab]
-
-New :guilabel:`Owner` tab
-+++++++++++++++++++++++++
-
-A new :guilabel:`Owner` tab displays the system's current owner and notify CC
-list. These fields previously lived in the system form. The system owner can
-change the notify CC list or give the system to another user from this tab.
-
-.. figure:: system-page-improvements-screenshots/owner-tab.png
- :width: 100%
- :alt: [screenshot of proposed Owner tab]
-
-New :guilabel:`Loan` tab
-++++++++++++++++++++++++
-
-A new :guilabel:`Loan` tab displays the current loan state of the system,
-including any comment which was recorded. Users can borrow, return, or lend the
-system (according to their permissions). Any user can also request a loan from
-this tab. A modal is shown for lending the system, but all other operations
-require a single click.
-
-This tab replaces the loan field and the associated :guilabel:`Loan Settings`
-modal window from the system form, as well as the loan request form which was
-previously accessed by clicking :guilabel:`Contact Owner` in the system form.
-
-.. figure:: system-page-improvements-screenshots/loan-tab.png
- :width: 100%
- :alt: [screenshot of proposed Loan tab]
-
-.. figure:: system-page-improvements-screenshots/lend-modal.png
- :width: 100%
- :alt: [screenshot of proposed Lend modal on Loan tab]
-
-New :guilabel:`Scheduler Configuration` tab
-+++++++++++++++++++++++++++++++++++++++++++
-
-Lastly, for want of any better place to put them, these three fields from the
-system form which relate to how the scheduler handles the system are placed in
-a new :guilabel:`Scheduler Configuration` tab:
-
-* Condition
-* Condition report
-* Type
-
-Like the :guilabel:`Hardware Essentials` tab, these fields are typically only
-of interest to the system owner.
-
-.. figure:: system-page-improvements-screenshots/scheduler-tab.png
- :width: 100%
- :alt: [screenshot of proposed Scheduler Configuration tab]
-
-Benefits of the improved system page
-------------------------------------
-
-As well as fixing the immediate issues with the system page layout, the
-proposed changes will address a number of other long-standing flaws or
-shortcomings in the system page.
-
-The system page has historically been one of Beaker's largest and most
-expensive pages to render, due to the amount of markup produced for all the
-widgets on the page. This proposal reduces the page size substantially, which
-will improve page load times for users.
-
-Furthermore, the new system page widgets update the page in place when a change
-is made, avoiding an expensive page refresh for every action. They use clearer
-and more consistent indications of progress, success, and failure. For example,
-power commands appear in the command queue as soon as they have been enqueued,
-without re-fetching the entire system page.
-
-The complete command queue will now be browsable in a grid on the
-:guilabel:`Commands` tab. Previously this was impossible due to the limitations
-of the TurboGears 1.x ``@paginate`` decorator.
-
-In future, once all widgets are taking advantage of the new asset packing
-introduced with Beaker 0.15, it will also be possible to reduce the number of
-HTTP requests needed to load the system page. Currently this has a very large
-impact on the first load time for Beaker pages. This proposal does not solve
-the problem but makes large strides towards an eventual solution.
-
-This proposal also takes small steps towards a more consistent and
-user-friendly interface across Beaker's entire web UI. All new system page
-widgets will adhere to Beaker's evolving :ref:`user interface guidelines
-<ui-guidelines>`, which were drafted as part of the work on this proposal.
-
-The following user interface bugs/RFEs will be solved by the system page
-improvements:
-
-* :issue:`692777` add a "duration" function on taken machines
-* :issue:`884399` cannot remove default install options when provisioning
- a manual system
-* :issue:`980352` no failure message when system update status can't be saved
-* :issue:`999391` loaning system to unknown user produced error 500
-* :issue:`999444` "Loan Settings" does not work on edit system page
-* :issue:`1009323` after someone tries to edit the system which he doesn't have
- permission, browser should show the origin page instead of homepage
-* :issue:`1009333` Beaker shows 500 error when someone tries to loan one system
- to others, but he only has loan-self permission
-* :issue:`1011284` button "Loan Settings" disappeared after clicking button
- "Return Loan"
-* :issue:`1011293` admin could see the button "Return Loan", even there is
- nobody was loaned to
-* :issue:`1020107` changing loan settings does not automatically update the
- system page
-* :issue:`1037280` meaning of "Hypervisor" field is not clear
-
-Related improvements to the Reserve Workflow
-++++++++++++++++++++++++++++++++++++++++++++
-
-As part of the proposed improvements, the Reserve Workflow page will also be
-updated to use Backbone and to add some new features. The three steps of the
-Reserve Workflow (distro selection, system selection, job submission) will be
-combined onto a single page, instead of being spread across three pages. It
-will be possible to link to the Reserve Workflow specifying a particular system
-to be reserved.
-
-.. figure:: system-page-improvements-screenshots/reserve-workflow.png
- :width: 100%
- :alt: [screenshot of proposed Reserve Workflow]
-
-Using this new feature, the system page can link to the Reserve Workflow for
-scheduling a reserve job. The :guilabel:`Provision` tab no longer needs to
-serve double duty for this purpose. Instead, it will be updated to always
-provision the system directly, not through the scheduler. This finally
-addresses a long-standing issue with the confusing behaviour of the
-:guilabel:`Provision` tab (see bug :issue:`855333` for background).
-
-.. figure:: system-page-improvements-screenshots/provision-tab.png
- :width: 100%
- :alt: [screenshot of proposed Provision tab]
-
-Deferred improvements
----------------------
-
-This proposal does not cover upgrading any of the existing tabs on the system
-page which are not affected by the removal of the system form. These tabs will
-retain their existing TurboGears 1.x style of behaviour: each operation
-triggers a page refresh and a TurboGears flash message to indicate success or
-failure.
-
-This proposal involves adding a number of new server-side interfaces for
-working with systems. They will be considered an internal Beaker implementation
-detail until they have been fleshed out and stabilized in a future release, at
-which point they may become public interfaces.
diff --git a/dev/proposals/system-pools.rst b/dev/proposals/system-pools.rst
deleted file mode 100644
index aa00699..0000000
--- a/dev/proposals/system-pools.rst
+++ /dev/null
@@ -1,154 +0,0 @@
-.. _proposal-system-pools:
-
-System Pools
-============
-
-:Author: Dan Callaghan, Nick Coghlan
-:Status: Deferred
-:Target Release: TBD
-
-
-Abstract
---------
-
-This proposal adds the ability to mark systems as members of various
-system pools. Job submitters can then express preferences and requirements for
-system pools in their jobs.
-
-
-Proposal deferral
------------------
-
-Further work on this proposal is currently deferred, pending research into
-the Apache Mesos scheduling meta-framework, and its potential suitability
-as a replacement for the current bespoke Beaker scheduler.
-
-
-Proposal
---------
-
-A "pool" is a named collection of systems.
-
-Each pool has an "owning group". Users in the owning group are allowed to add
-and remove systems from the pool.
-
-Job submitters may influence the system selection through the job XML.
-
-
-Proposed user interface
------------------------
-
-Defining ad hoc system pools
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* As a Beaker user, I want to define a new pool of systems.
-
-Through the web UI:
-
- Select "Systems -> Pools" from the menu, then click "Create". Enter the
- pool name, and select a group to own the pool.
-
-Through the ``bkr`` cli::
-
- bkr pool-create --owner-group=<groupname> <poolname>
-
-A new pool is created containing no systems.
-
-
-Controlling system pool membership
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* As a pool owner, I want to add a system to my pool.
-
-Through the web UI:
-
- On the system page, click the "Pools" tab. Enter the name of the pool and
- click "Add".
-
-Through the ``bkr`` cli::
-
- bkr pool-add --pool=<poolname> --system=<fqdn>
-
-* As a pool owner, I want to remove a system from my pool.
-
-Through the web UI:
-
- On the system page, click the "Pools" tab. Click "Remove" next to your pool.
-
-Through the ``bkr`` cli::
-
- bkr pool-remove --pool=<poolname> --system=<fqdn>
-
-
-Restrict recipe execution to a specific system pool
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* I want to submit a job and limit it to systems in a particular pool.
-
-Through the job XML:
-
- Use ``<pool op="=" value="somepool" />`` in the
- ``<hostRequires/>`` of your job XML.
-
-Through the ``bkr`` cli:
-
- Pass ``--hostrequire=pool=somepool`` to a workflow command.
-
-This filter will select only systems which are in the given pool.
-
-
-Prefer particular system pools for recipe execution
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* I want to submit a job and express an ordered preference regarding
- the pools where I would like the job to run.
-
-Through the job XML:
-
- Use ``<autopick/>`` in the ``<recipe/>`` section of the job XML, with a
- sequence of ``<pool/>`` elements::
-
- <autopick>
- <pool>somepool</pool>
- <pool>anotherpool</pool>
- </autopick>
-
- There is an implied "other systems" at the end, which covers all other
- systems which the user has access to (use ``<hostRequires/>`` to limit
- a job to specific system pools).
-
- When ``random="true"`` is set on the autopick element, the pool order
- in the XML is still used, but the specific system used is selected
- randomly from within each pool (or the implied "other systems" after
- the list of specific pools is exhausted). To select randomly from
- multiple pools without expressing a preference between them, use
- an empty ``<autopick random="true" />`` element and several
- ``<pool/>`` selection elements grouped under a ``<or/>`` element
- in the ``<hostRequires/>`` section of the job XML.
-
-
-Deferred features
------------------
-
-The following additional features are under consideration, but have been
-deliberately omitted in order to reduce the complexity of the initial
-iteration of the design:
-
-* Adding other pools as members of a pool. The initial iteration
- does not allow pools to be members of other pools, which introduces
- potential concerns about scalability in large organisations.
-
- Adding this feature may also make it possible to effectively delegate
- the ability to add systems to other pools.
-
- See the deferred subgroups feature in :ref:`proposal-enhanced-user-groups`
- for a possible implementation strategy that could also be used for
- system subpools.
-
-* Pool deletion. The initial iteration does not allow pools to be deleted,
- or even hidden. This feature may actually be needed to make various other
- parts of the UI usable, in which case it will be designed and implemented
- for the target release (and the design proposal updated accordingly).
-
-* Allowing users to specify a default pool preference to be used when there
- is no ``autopick`` section in the submitted recipe XML.
diff --git a/dev/proposals/time-limited-manual-reservations.rst b/dev/proposals/time-limited-manual-reservations.rst
deleted file mode 100644
index cdf88ab..0000000
--- a/dev/proposals/time-limited-manual-reservations.rst
+++ /dev/null
@@ -1,127 +0,0 @@
-.. _proposal-time-limited-manual-reservations:
-
-Time Limited Manual Reservations
-================================
-
-:Author: Nick Coghlan
-:Status: Deferred
-:Target Release: TBD
-
-
-Abstract
---------
-
-This proposal redesigns the current external watchdog mechanism, allowing
-it to be used even for systems that are not currently running a recipe. This
-new reservation timer is then used to offer time limited manual reservations.
-
-To assist with voluntarily returning system loans, it is also proposed that
-the ability be added to indicate when reserving a system manually that the
-loan should also be returned when the reservation is returned.
-
-
-Proposal deferral
------------------
-
-Further work on this proposal is currently deferred, as the remote API
-improvements in Beaker 0.15 now allow greater control of Beaker systems
-from external services, and the ability to force recipe execution on
-Manual systems in Beaker 0.17 will further enhance that capability.
-
-This proposal needs to be reassessed after further experience has been gained
-with the impact of those changes.
-
-
-Recipe independent watchdog timers
-----------------------------------
-
-A new "expiry_time" attribute will be added to reservation records.
-
-The existing "kill_time" attribute on external watchdog records will be
-replaced with a reference to the appropriate reservation.
-
-For reservations made through the job scheduler, very little will change.
-Wherever the kill time for the watchdog would previously have been set or
-modified, the expiry time on the reservation will be updated instead. The
-details of the currently running task and subtask will still be recorded
-on the watchdog and the ``beaker-watchdog`` daemon on the lab controller
-will still be responsible for monitoring for an expired watchdog and
-aborting the recipe as appropriate.
-
-For reservations made directly through the web UI, the web UI will be updated
-to allow specification of a duration when taking the system. The default will
-continue to be no time limit, but if a time limit is requested, then the
-default will be 24 hours (configurable as a global Beaker server setting).
-If a time limit is requested, then the reservation expiry date will be set
-appropriately.
-
-While a reservation is active, the reserving user may extend it through the
-web UI or the ``bkr`` CLI, as well as using the ``extendtesttime.sh`` script
-on the reserved system (if that script is installed, as it is by the
-``/distribution/reservesys`` task).
-
-The reserving user may also return the system early, either by cancelling the
-job (for an automatic reservation), or explicitly (for a manual reservation).
-The ``return2beaker.sh`` script can also be called from the reserved system
-(if that script is installed, as it is by the ``/distribution/reservesys``
-task).
-
-While the ``beaker-watchdog`` daemons on the individual lab controllers will
-continue to handle reservation expiry for systems executing recipes, the
-Beaker scheduling daemon will periodically check for expired manual
-reservations and automatically return them.
-
-
-Automatically returning loans
------------------------------
-
-When reserving a system, a user will be able to choose to automatically
-return a loan. If this option is specified, then when the reservation is
-returned, the active system loan will also be returned.
-
-As long as the reservation remains in effect, the user with the loan and
-linked reservation will be able to edit this setting.
-
-This will be stored as a new ``return_loan`` attribute on each reservation.
-
-(also see :issue:`651477`)
-
-
-User interface proposals
-------------------------
-
-Web UI
-~~~~~~
-
-TBD
-
-Command line
-~~~~~~~~~~~~
-
-TBD
-
-
-Rejected features
------------------
-
-* Moving responsibility for watchdog expiry from the lab controller to the
- main server even for systems in Automated mode (as doing so would break
- the existing ability to execute watchdog script on the lab controller)
-
-* Removing the watchdog table (as doing so would require more invasive
- changes that aren't needed to achieve the aims of this proposal)
-
-* Allowing the now deferred ``reservesys`` element to be specified at the job
- level, since it isn't clear how that would work when recipe sets are run at
- different times.
-
-* Having "onpass" default to false in the now deferred ``reservesys element``.
- While this is desirable in some respects, having different defaults for one
- of the items is difficult to document clearly.
-
-
-References
-----------
-
-* `Discussion thread for first draft of this proposal
- <https://lists.fedorahosted.org/pipermail/beaker-devel/2013-September/000771.html>`__
diff --git a/dev/proposals/time-limited-system-loans.rst b/dev/proposals/time-limited-system-loans.rst
deleted file mode 100644
index 4d9bd1d..0000000
--- a/dev/proposals/time-limited-system-loans.rst
+++ /dev/null
@@ -1,109 +0,0 @@
-.. _proposal-time-limited-system-loans:
-
-Time Limited System Loans
-=========================
-
-:Author: Nick Coghlan
-:Status: Deferred
-:Target Release: TBD
-
-
-Abstract
---------
-
-Prompt return of system loans is currently entirely dependent on the
-user with the loan remembering to return the system, or another user with
-sufficient permissions on the system returning it on their behalf.
-
-A time limiting mechanism is proposed for system loans, that automatically
-returns the loan when the nominated duration expires. Unlike time limited
-manual reservations (:ref:`proposal-time-limited-manual-reservations`),
-users would not be able to extend their loans without appropriate permissions
-on the system (either ``loan_self`` to extend only their own loans, or
-``loan_any`` to extend anyone's loaning, including their own).
-
-To avoid surprising users when their loans are returned automatically, the
-"alert email" mechanism described in
-:ref:`proposal-time-limited-manual-reservations` would be updated to include
-notifications of expiring loans.
-
-
-Proposal deferral
------------------
-
-Further work on this proposal is currently deferred, as the remote API
-improvements in Beaker 0.15 now allow greater control of Beaker systems
-from external services, and the ability to force recipe execution on
-Manual systems in Beaker 0.17 will further enhance that capability.
-
-This proposal needs to be reassessed after further experience has been gained
-with the impact of those changes.
-
-
-Time limited loans
-------------------
-
-System loans will be separated out to be tracked explicitly (similar to
-the handling of reservations, only without the "type" field). When loaning
-the system, the user granting the loan will be able to specify a duration
-of the loan, which will be recorded as a loan expiry time. The default will
-continue to be no time limit, but if a time limit is requested, then the
-default will be 7 days (configurable as a global Beaker server setting).
-
-While a loan is active, it may be extended. However, the user extending the
-loan must have ``loan-self`` (for their own loans) or ``loan-any`` (for other
-users' loans) permissions on the system. This means that system loans can
-be used to impose hard deadlines on reservations, as a user that is granted
-a time limited loan but does not possess the ``reserve``, ``loan-self`` or
-``loan-any`` on the system can only receive more time by requesting it
-from a user with ``loan-any`` permissions on that system.
-
-If a system loan has an expiry time configured, then all reservations
-(whether manually or through the scheduler) made by that user are
-automatically time limited, defaulting to the loan expiry time or the
-normal default reservation time, whichever is earlier.
-Attempts to extend the deadline of a system reservation beyond the end of
-the loan period will fail.
-
-The Beaker scheduling daemon will periodically check for expired loans
-and automatically return them. For reserved systems where the reservation
-is from a user that is no longer permitted to access the system once the
-loan has been returned, it will also return the reservation or cancel the
-recipe as appropriate.
-
-(See also: :issue:`651479`)
-
-
-Beaker usage report emails
---------------------------
-
-The usage alert email mechanism described in
-:ref:`proposal-time-limited-manual-reservations` will be updated to include
-a new alert condition and section in the alert email:
-
-* Expiring Loans
-
- * they have a time limited loan that will expire within 25 hours
-
-The given limit would be a server configuration options, with this value as
-the default.
-
-
-User interface proposals
-------------------------
-
-Web UI
-~~~~~~
-
-TBD
-
-Command line
-~~~~~~~~~~~~
-
-TBD
-
-References
-----------
-
-* `Discussion thread for first draft of this proposal
- <https://lists.fedorahosted.org/pipermail/beaker-devel/2013-September/000771.html>`__
diff --git a/dev/related-projects.rst b/dev/related-projects.rst
deleted file mode 100644
index 3ae173e..0000000
--- a/dev/related-projects.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-.. _related-projects:
-
-Related Projects
-================
-
-Beah
-----
-
-`Beah <http://beah.readthedocs.org/>`__ is the default test
-harness used in Beaker.
-
-restraint
----------
-
-`Restraint <https://github.com/p3ck/restraint>`__ is a minimal test
-harness implementation for Beaker.
-
-BeakerLib
----------
-
-`BeakerLib <https://fedorahosted.org/beakerlib/wiki/Manual>`__ is a
-library useful for writing `Beaker tasks
-<../docs/user-guide/writing-tasks.html>`__.
-
-Jenkins Beaker builder plugin
------------------------------
-
-The `Jenkins Beaker builder plugin
-<https://wiki.jenkins-ci.org/display/JENKINS/Beaker+Builder+Plugin>`__
-integrates Jenkins with Beaker.
-
-Integration with autotest
--------------------------
-
-This is a work in progress which aims to integrate autotest and
-Beaker. See `here
-<https://lists.fedorahosted.org/pipermail/beaker-devel/2013-November/000843.html>`__
-for some relevant discussions and the patch `here
-<https://github.com/autotest/autotest/pull/629>`__.
-
-Fedora's Beaker instance
-------------------------
-
-The Fedora project maintains a Beaker installation `here
-<https://beaker.fedoraproject.org>`__.
diff --git a/dev/tech-roadmap.rst b/dev/tech-roadmap.rst
deleted file mode 100644
index dc7065a..0000000
--- a/dev/tech-roadmap.rst
+++ /dev/null
@@ -1,462 +0,0 @@
-.. _technical-roadmap:
-
-Technical roadmap
-=================
-
-Beaker is a big project, with a lot of moving parts. It's been around for
-quite a while, and is used in several different ways by different groups
-of people.
-
-This technical roadmap is designed to highlight areas of currently active
-development, as well as more speculative changes that may happen at some
-point in the future. :ref:`design-proposals` describe the major
-changes and some of them are also referenced here.
-
-If any of these projects sound particularly interesting, folks are welcome to
-:doc:`get involved <guide/index>`.
-
-Active development
-------------------
-
-The ideas in this section are currently under active development. Patches for
-at least some of these are likely to be found on the `Beaker Gerrit server
-<http://gerrit.beaker-project.org>`_, and in the absence of unexpected
-complications, they should show up in a Beaker release within the next few
-months. Searching `Bugzilla
-<https://bugzilla.redhat.com/buglist.cgi?product=Beaker&bug_status=__open__>`_
-for Beaker bugs with target milestones set will often provide more detail on
-the specific proposals.
-
-Web UI modernisation
-~~~~~~~~~~~~~~~~~~~~
-
-The current main web UI is based on the TurboGears 1 stack (although it
-uses SQLAlchemy rather than SQLObject for the database access layer). This
-makes some aspects of development more awkward than they might be with a
-more recent web framework.
-
-Starting with the Beaker 0.15 release, the main web server is in the
-process of being migrated to Flask, by allowing endpoints to be
-implemented as either TG1 controllers or Flask handlers. We are also
-aiming to replace the front end components with cleaner alternatives
-based on Twitter Bootstrap.
-
-The systems page is being redesigned completely and is described in
-the :ref:`proposal-system-page-improvements` design proposal.
-
-
-Improved inventory task
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The current inventory task is based on the ``smolt`` project. Replacing this
-with a new version based on ``lshw`` will improve many aspects of the
-system capability reporting, providing a richer set of attributes to
-query on a larger set of hardware architectures.
-
-This idea is covered by the :ref:`proposal-lshw-migration` design
-proposal.
-
-Run tests from inside a container
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Project Atomic uses rpm-ostree to manage the host environment, so we
-can't install arbitrary additional packages. However, an Atomic host
-provides the bare minimum of infrastructure needed to run containers
-and hence having the ability to run tests inside of a container
-instead of the host would be a useful feature to have
-(:issue:`1131388`).
-
-
-Planned development
--------------------
-
-The ideas in this section are firmly on the to-do list, but it is not yet
-clear when they will be ready for inclusion.
-
-
-Explicit system pools
-~~~~~~~~~~~~~~~~~~~~~
-
-Beaker currently schedules jobs on any system the user has access to,
-preferring the users own systems over group systems, over the generally
-accessible system pool.
-
-This approach isn't always desirable, since some systems have special
-features that should only be used when explicitly requested, or a user may
-wish to target a specific job at a particular set of machines.
-
-Allowing systems to be grouped into pools (independent of the access policies
-used to grant or deny access to the systems) will allow users to express
-more abstract preferences about machines that aren't directly related to
-the system itself.
-
-This idea is covered by the :ref:`proposal-system-pools` design proposal.
-
-
-Event based scheduler
-~~~~~~~~~~~~~~~~~~~~~
-
-The current scheduler has some issues and limitations that are best resolved
-by switching to a more event-driven architecture. The new design will
-involve attempting to assign newly submitted recipes to an idle system
-without placing the recipe in the main queue, and newly available systems
-to queued recipes without placing the system in the idle pool.
-
-This idea is covered by the :doc:`proposals/event-driven-scheduler` design
-proposal.
-
-
-More flexible job prioritisation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Armed with the new user group and access policy models, and the new event
-driven approach to scheduling, it becomes possible to offer system owners
-much greater control over which recipes are selected to run on their
-systems.
-
-This idea is covered by the :doc:`proposals/effective-job-priorities` design
-proposal.
-
-
-Task oriented guides for users and administrators
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Beaker offers a lot of power and flexibility, but that can often come at
-the price of making the right way to do certain things non-obvious. Beaker's
-documentation is likely to benefit from additional sections that take a
-"task-based" approach to documentation and answer questions like "How do I
-limit my recipe to systems with a graphics adapter?" or "How do I require
-that my recipe run directly on bare metal and not in a VM?".
-
-This will include a general "troubleshooting guide" to help users and
-administrators collaborate effectively in tracking down the more obscure
-failures that can occur with the kind of integration testing Beaker
-supports.
-
-
-Systematic self-tests for provisioning and beah
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-As a tool for better validating new Beaker releases, as well as making it
-easier to check for the correct operation of new Beaker installations, a
-set of self-test Beaker tasks will be made readily available. These tasks
-should come with helper scripts scripts for installing them into a
-Beaker installation and the appropriate job definitions to execute them
-across all configured architectures and distro trees.
-
-
-Integration with Teiid and Metrique
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To quote their project descriptions, `Teiid <https://www.jboss.org/teiid/>`__
-is a "data virtualization system that allows applications to use data from
-multiple heterogenous data stores", while `Metrique
-<https://github.com/kejbaly2/metrique>`__ provides a "simple Python and REST
-API for ETL (extract, transform, load) workloads" and "tight clientside
-integration with popular python scientific computing libraries".
-
-What this means for Beaker is that Teiid can be used to extract data from a
-Beaker database for data mining purposes, while Metrique is a data mining
-tool that serves to make that data readily available to scientific
-computing analysis and visualisation tools (including `IPython notebooks
-<http://ipython.org/notebook>`__).
-
-Integrating cleanly with data mining tools is a better approach to building
-prediction tools for large Beaker instances than attempting to add such
-analytical capabilities to Beaker itself. Even if an installation uses other
-data extraction and warehousing systems, Teiid and Metrique based examples
-in the Beaker repos may serve as an illustrative guide.
-
-Shared access policies
-~~~~~~~~~~~~~~~~~~~~~~
-
-Beaker 0.15 implemented the first phase of the :ref:`proposal-access-policies`
-design proposal, taking the previously limited permissions model for
-individual systems and providing a far more fine-grained model. Remote
-access through the Beaker command line client makes it possible to manage
-access to large numbers of systems this way.
-
-A future release will implement the second phase of the
-:ref:`proposal-access-policies` proposal, separating out access policies as
-a distinct entity in Beaker's user interface, allowing a common access policy
-to be shared amongst multiple systems (system access policies are already a
-distinct concept in the data model, but cannot currently be shared
-across multiple systems).
-
-
-Improved handling of reservations and system loans
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-While systems in Beaker can currently be loaned to other users, the workflows
-for doing so aren't particularly convenient. It would be helpful if
-Beaker included better tools for managing System Loans, as well as a
-system for automatically returning them if unused for extended periods.
-
-This also applies to reservations, especially allowing automated
-reservations without relying on the use of a particular test harness.
-
-These ideas are covered by :ref:`proposal-time-limited-manual-reservations`
-and :ref:`proposal-time-limited-system-loans`.
-
-:issue:`734212` covers providing a command line interface to manage system
-loans.
-
-
-
-Exploration
------------
-
-The ideas in this section are projects that one or more of the current
-developers are at least tinkering with, but they may be at wildly
-divergent stages of maturity.
-
-xUnit and subunit output support
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-While a Jenkins plugin to trigger Beaker jobs is available, the reporting is
-currently limited as Beaker doesn't provide job results in a format that
-Jenkins understands.
-
-It would be helpful if Beaker supported exporting the results of jobs in
-xUnit format. The nose `xunit plugin
-<http://nose.readthedocs.org/en/latest/plugins/xunit.html>`__ may be a
-useful guide to this (:issue:`1123244`).
-
-A potentially related change would be to support retrieval of
-`subunit results <https://pypi.python.org/pypi/python-subunit>`__ for
-in-progress jobs.
-
-
-Reference harness implementation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-At present all Beaker recipes are run with the same harness, Beah. We would
-like to develop a minimal "reference harness" implementation, so that we can
-experiment with some harness features which would be disruptive or difficult to
-implement in Beah.
-
-This idea is covered by the :doc:`proposals/reference-harness` design proposal.
-
-Full Fedora compatibility
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We would like to support Fedora as a host operating system for the Beaker
-server components. This work was mostly completed in Beaker 0.14 (supporting
-Fedora 19+), but there are ongoing issues with upgrades of dependencies
-that don't currently have solid backwards compatibility policies.
-
-The current plan is to start running Beaker's continuous integration tests
-in Fedora's `Beaker instance <http://beaker.fedoraproject.org>`__ (on Fedora),
-in addition to running them on RHEL6.
-
-We also plan to resolve the remaining packaging issues preventing inclusion
-of Beaker and its dependencies directly in the main Fedora package
-repositories.
-
-Integrated live dashboard
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-While Beaker 0.11 started sending aggregate metrics for the current system
-status directly to Graphite, it doesn't provide any native dashboard
-capability. It's desirable to provide an improved dashboard experience,
-using either Graphite's native dashboard tools, or a richer Javascript based
-charting front end (such as Rickshaw).
-
-Test suite speed improvements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Beaker's Web UI is tested using the Selenium WebDriver API to drive
-Mozilla Firefox. Using `SlimerJS <http://slimerjs.org/>`__ instead may
-decrease the runtime for the test suite considerably.
-
-Job based recipe access limitations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Running recipes can currently inadvertently interfere with systems running
-recipes for unrelated jobs. While it is intentional that recipes can control
-systems other than the one they are running on, there should really be a
-mechanism that limits this access to only those systems running other
-recipes within the same recipe set.
-
-Guided editor for job definition XML
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Currently, many Beaker users rely on automated generators to create full
-Beaker job definition files from a handful of parameters. This idea is to
-use the Relax-NG schema for the job XML, as well as appropriate live queries
-of the Beaker database, to create a guided editor that will help users to
-create job definitions directly, rather than relying on automated
-generators that may expose only a fraction of Beaker's full flexibility.
-
-More complex example tasks
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Kerberos and LDAP integration are notoriously hard features to test, and
-many automated test suites simply don't bother. Beaker, however, is fully
-capable of testing Kerberos and LDAP integration, along with AMQP. This
-idea is to make sure the implementations of these tests for Beaker's own
-testing are also used as examples of Beaker's capabilities.
-
-Unifying ``hostRequires`` filtering and web UI search functionality
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Beaker's job processing and the web UI both allow a user to identify a
-subset of interest within the full set of available systems. The user
-interface for these is necessarily different, as once is based on the XML
-file defining a job, while the other is defined through an interactive web
-form.
-
-However, rather than being thin wrappers around a shared internal filter
-creation API, the dynamic filter creation implementations in these
-components are almost completely separate. This means that capabilities
-are sometimes added to the ``hostRequires`` processing and not to the web
-UI, or vice-versa.
-
-It seems like it should be possible to substantially reduce the level of
-duplication between these two components, and thus make it easier to add
-new filtering and sorting criteria in the future.
-
-Raw SQL query API
-~~~~~~~~~~~~~~~~~
-
-To further help integration with data mining tools, it may be useful to
-provide the ability to query a running Beaker server for the equivalent
-SQL needed to answer certain API queries (:issue:`888102`).
-
-
-Speculative ideas
------------------
-
-The ideas in this section aren't really in development at all. Instead,
-they reflect capabilities we think we'd *like* Beaker to have, or other
-improvements we'd like to make, and may even have some initial design
-sketches behind them. While there are no current concrete plans to do
-anything about any of the ideas in this section, we're certainly open to
-discussing them and reviewing any proposed patches related to them.
-
-Most of these are at least non-trivial projects, and it's an open question
-if some of them are feasible at all. Some of them may prove to be bad ideas,
-regardless of feasibility.
-
-
-Automated classification of intermittent and spurious test failures
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OpenStack CI infrastructure includes a tool called "Elastic Recheck".
-Essentially what they do is take the automated logs from particular
-OpenStack CI runs, feed them into an ElasticSearch instance, and then run
-various classifiers over those logs. Elastic Recheck then posts back to
-the failed change proposal, indicating the likely cause of the failure (and
-potentially triggering a second check attempt).
-
-While such a tool wouldn't need to be part of Beaker itself, it may still be
-a useful feature to explore, and there may be a place for publishing suitable
-classifiers in a related project.
-
-A Beaker installation could potentially make use of such a tool in two ways.
-Firstly, Beaker includes the concept of "result acknowledgements", where
-users can "NAK" a result to indicate that it wasn't a valid test run (for
-example, there was an error in the test else, or something failed in the
-lab environment). An Bayesian classifier could be used to scan the logs of
-NAKed results, looking for patterns that are likely to indicate these kinds
-of "failures", which don't actually reflect a fault in the software being
-tested.
-
-Secondly, for genuine test failures, a Bayesian classifier could be used to
-identify log data that is likely to correspond with a failed test, and
-suggest that as a probable cause when a test fails, rather than requiring
-users to trawl through the logs themselves. This is one of the key approaches
-the OpenStack CI team used to build their Elastic Recheck tool - many of
-the common failures were identified by automated scanning of previous failed
-test runs rather than by identifying the causes of the failure directly.
-
-
-Provisioning other hypervisors
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Beaker provides rich "guest recipe" functionality for testing installation
-and other operations within a KVM based virtual machine. Testing against
-non-KVM hypervisors is possible, but more awkward, as the guest VMs must be
-precreated and registered with Beaker as full systems with appropriate
-custom power scripts that handle the process of starting and stopping the
-underlying virtual machines. This is an unfortunate limitation.
-
-Asynchronous message queues
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The provisioning service on the lab controllers currently receives
-commands by polling a command queue stored on the main server. Similarly,
-the main task scheduler polls the database to determine when new
-and queued recipes can be assigned to systems.
-
-It may be worth adopting `fedmsg <http://www.fedmsg.com>`__, or something
-similar, to help get rid of these polling calls.
-
-Alternate database backend
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The only currently supported database backend for the main server is MySQL
-(or an equivalent, like MariaDB). There are all sorts of reasons why this
-isn't good, but migrating to PostgreSQL isn't straightforward. The two main
-issues to be addressed are the handling of queries where MySQL and
-PostgreSQL have drastically difference performance characteristics
-(and there's no solution that performs well in both), and the
-challenge of actually doing a data migration for any existing
-Beaker installations.
-
-The status of ``beah``
-----------------------
-
-In many respects, ``beah``, the native Beaker test harness, duplicates aspects
-of other test frameworks like `autotest <http://autotest.github.io/>`__ and
-`STAF <http://staf.sourceforge.net/>`__.
-
-Being so heavily dependent on kickstart files and the RPM based task library,
-``beah`` is also quite inflexible in terms of platform support.
-
-The following kinds of changes will be considered for ``beah``:
-
-* documentation improvements
-* compatibility updates for supported test systems
-* any changes needed for image based provisioning with OpenStack
-* any changes needed for IPv6 compatibility
-* reliability fixes
-* equivalent capabilities for additions made to the stable harness API
-
-Outside these areas, we consider it a poor use of resources to further
-duplicate the effort going into development of other automated test
-harnesses (especially ``autotest``), and hence any major feature proposals for
-``beah`` will likely be rejected - we would prefer for any such efforts to
-be directed towards the system changes needed to better support alternative
-harnesss.
-
-To support existing Beaker users, the ``beah`` test harness will be
-maintained indefinitely, and the kinds of changes noted above will continue
-to be permitted. The only way ``beah`` itself would ever be phased out is if
-a simpler and more robust alternative became available and was capable of
-correctly executing all of the existing Beaker tests that the core Beaker
-developers have access to. The :doc:`proposals/reference-harness` design
-proposal is expected to lead to the eventual creation of just such a harness.
-
-Recently implemented ideas
---------------------------
-
-The following ideas were previously included on this roadmap, but are
-now implemented in Beaker:
-
-- `Experimental support for Open Stack based dynamic virtualization <http://beaker-project.org/docs/whats-new/release-0.17.html>`__
-- `Installation specific theming of the Web UI <https://beaker-project.org/docs/whats-new/release-0.17.html#theming-the-web-interface>`__
-- `Virtual only test bed for Beaker <https://beaker-project.org/dev/guide/virtual-fedora/>`__
-- `IPv6 support in the default test harness <http://beah.readthedocs.org/en/latest/admin.html#using-beah-for-ipv6-testing>`__
-- `Delegating job submission <../docs/whats-new/release-0.14.html#submission-delegates>`__
-- `Separate system architecture guide <../docs/whats-new/release-0.14.html#architecture-guide>`__
-- `Jenkins plugin to launch Beaker jobs <https://lists.fedorahosted.org/pipermail/beaker-devel/2013-July/000657.html>`__
-- `Self-service user groups <../docs/whats-new/release-0.13.html#more-flexible-user-groups>`__
-- `Group ownership of jobs <../docs/whats-new/release-0.13.html#group-jobs>`__
-- `autotest support for stable harness API <https://github.com/autotest/autotest/pull/629>`__
-- `Stable harness API <../docs/whats-new/release-0.12.html#provisional-support-for-alternative-harnesses>`_
-- `Working with multiple Beaker instances
- <../docs/whats-new/release-0.12.html#other-enhancements>`_
-
-
-
diff --git a/docs/conf.py b/docs/conf.py
deleted file mode 100644
index 6f481d2..0000000
--- a/docs/conf.py
+++ /dev/null
@@ -1,32 +0,0 @@
-
-# vim: set fileencoding=utf-8 :
-
-# The real conf.py lives in Beaker's source, so we load it from there and then
-# override some template settings below.
-import os, os.path
-execfile(os.path.join(os.environ['BEAKER'], 'documentation', 'conf.py'))
-
-html_theme = 'beaker'
-html_theme_path = ['../sphinx-theme']
-
-intersphinx_mapping['python'] = ('http://docs.python.org/',
- os.path.join(os.path.dirname(__file__), '..', 'python-intersphinx.inv'))
-intersphinx_mapping['beakerdev'] = ('../dev/',
- os.path.join(os.path.dirname(__file__), '..', 'dev', 'objects.inv'))
-
-keep_warnings = True
-
-html_context = {}
-if os.path.basename(os.environ['BEAKER']) == 'master':
- html_context['branch_warning'] = ''
-elif os.path.basename(os.environ['BEAKER']) == 'develop':
- html_context['branch_warning'] = u"""
- You are viewing the development version of Beaker’s documentation. It
- is not final and may be changed before the next release.
- """
-else:
- html_context['branch_warning'] = u"""
- You are viewing a branched version of Beaker’s documentation. The
- latest released version of the documentation contains more
- up-to-date information.
- """
diff --git a/generate-docs-mk.sh b/generate-docs-mk.sh
deleted file mode 100755
index 9331262..0000000
--- a/generate-docs-mk.sh
+++ /dev/null
@@ -1,28 +0,0 @@
-#!/bin/bash
-# vim: set noexpandtab:
-
-dests=()
-for branch_dir in beaker-branches/* ; do
- if [[ "$branch_dir" == */master ]] ; then
- dest=docs
- else
- dest="docs-$(basename "$branch_dir")"
- fi
- dests+=("$dest")
- echo ".PHONY: $dest"
- echo "$dest: $branch_dir dev"
- cat <<"EOF"
- mkdir -p $@
- # The templated version moved in Beaker 0.13. We ensure
- # both are generated for the sake of older branches.
- $(MAKE) -C $</Common bkr/__init__.py bkr/common/__init__.py
- # This __requires__ insanity is needed in Fedora if multiple versions of CherryPy are installed.
- BEAKER=$(abspath $<) \
- PYTHONPATH=$</Common:$</Server:$</Client/src \
- python -c '__requires__ = ["CherryPy < 3.0"]; import pkg_resources; execfile("$(SPHINXBUILD)")' \
- $(SPHINXBUILDOPTS) -c docs/ -b html $</documentation/ $@/
-EOF
- echo
-done
-echo ".PHONY: all-docs"
-echo "all-docs: ${dests[@]}"
diff --git a/publish.sh b/publish.sh
deleted file mode 100755
index 7ac1c67..0000000
--- a/publish.sh
+++ /dev/null
@@ -1,86 +0,0 @@
-#!/bin/bash
-
-set -ex
-
-if [[ $1 == "--skip-yum" ]] ; then
- skip_yum=1
-fi
-
-# Make sure we have the latest published version.
-git fetch beaker-project.org:/srv/www/beaker-project.org/git master:published
-
-# This is the SHA of the current tip of the destination branch,
-# on top of which we will commit our new version.
-parent=$(git rev-parse refs/heads/published)
-
-if [ "$(git rev-parse HEAD)" = "$parent" ] ; then
- echo "Don't checkout the published branch!" >&2
- exit 1
-fi
-
-# Sanity check: the commit from which the current destination branch was built,
-# must be an ancestor of the commit we are building from now.
-if ! git rev-list HEAD | grep -q $(git show $parent:git-rev) ; then
- echo "Error: tip of 'published' was built from" >&2
- git show $parent:git-rev >&2
- echo "which is not an ancestor of HEAD" >&2
- exit 1
-fi
-
-D=/tmp/beaker-project.org-publish-work-tree
-rm -rf "$D"
-mkdir -p "$D"
-# check out HEAD of beaker-project.org into $D
-GIT_DIR=$(pwd)/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish GIT_WORK_TREE="$D" git read-tree HEAD
-GIT_DIR=$(pwd)/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish GIT_WORK_TREE="$D" git checkout-index -a -f
-GIT_DIR=$(pwd)/.git git rev-parse HEAD >"$D/git-rev"
-# check out each branch submodule of beaker
-# (can't use git-submodule for this since it complains about needing a work tree)
-GIT_DIR=$(pwd)/.git git ls-tree -r HEAD | grep ^160000 |
-while read mode type sha path ; do
- GIT_DIR=$(pwd)/$path/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish-beaker GIT_WORK_TREE="$D" git read-tree --empty
- GIT_DIR=$(pwd)/$path/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish-beaker GIT_WORK_TREE="$D" git read-tree --prefix=$path/ $sha
- GIT_DIR=$(pwd)/$path/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish-beaker GIT_WORK_TREE="$D" git checkout-index -a -f
- echo $sha >"$D/git-rev-beaker-$(basename $path)"
-done
-
-# Carry existing release artifacts and RPMs over to the build directory,
-# because they are quite expensive to build/fetch and they never change.
-# This is purely an optimisation so ignore failures.
-mkdir -p "$D/releases" || :
-cp -p --reflink=auto releases/*.tar.* releases/*.patch "$D/releases/" || :
-mkdir -p "$D/yum/rpms" || :
-cp -p --reflink=auto yum/rpms/*.rpm "$D/yum/rpms/" || :
-
-if [[ -n "$skip_yum" ]] ; then
- # check out published yum subdir into $D/yum, we are not going to rebuild it
- rm -rf "$D/yum/rpms"
- GIT_DIR=$(pwd)/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish-yum GIT_WORK_TREE="$D/yum" git read-tree published:yum
- GIT_DIR=$(pwd)/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish-yum GIT_WORK_TREE="$D/yum" git checkout-index -a -f
- make -j4 -C "$D" BEAKER_GIT="$(pwd)/.git/modules/beaker-branches/master" all-docs all-website
-else
- make -j4 -C "$D" BEAKER_GIT="$(pwd)/.git/modules/beaker-branches/master" all
-fi
-
-# Clean out junk that we don't want to publish.
-find "$D" -name .doctrees -exec rm -r {} \+
-
-GIT_DIR=$(pwd)/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish GIT_WORK_TREE="$D" git add -f -A "$D"
-tree=$(GIT_DIR=$(pwd)/.git GIT_INDEX_FILE=$(pwd)/.git/index-publish git write-tree)
-commit=$(git commit-tree $tree -p $parent -p $(git rev-parse HEAD) <<EOF
-Automatic commit of generated web site from $(git rev-parse HEAD)
-EOF
-)
-
-# Sanity check: did the new commit delete or change any lines in
-# releases/SHA1SUM? This is verboten!
-deleted=$(git diff $parent..$commit --numstat -- releases/SHA1SUM | cut -f2)
-if [[ "$deleted" -gt 0 ]] ; then
- echo "Checksum of released artefact changed!"
- git diff $parent..$commit -- releases/SHA1SUM | cat
- exit 1
-fi
-
-git update-ref refs/heads/published $commit $parent
-
-rm -rf "$D"