Merge lp:~andreserl/maas/lp1665143 into lp:maas/2.1

[Andres Rodriguez]

Unmerged revisions

5758. By Andres Rodriguez on 2017-02-27

Make updates

5757. By Andres Rodriguez on 2017-02-27

Make updates

5756. By Andres Rodriguez on 2017-02-22

Work around issue when discovering nvme

5755. By Andres Rodriguez on 2017-02-22

[r=andreserl,mpontillo][bug=][author=andreserl] Ensure that we can discover a wedge BMC even if we detect a connected 'ipmi' device

5754. By Gavin Panella on 2017-02-22

[r=blake-rouse][bug=][author=allenap] Concurrent calls to getClientNow will not cause an update storm.

5753. By Newell Jensen on 2017-02-22

[r=lamont][bug=1665839][author=newell-jensen] Sieve the newly composed machine based off of node_id.

5752. By Gavin Panella on 2017-02-21

[r=allenap][bug=][author=allenap] Add to the list of development packages needed for Yakkety and Zesty.

5751. By Gavin Panella on 2017-02-20

[r=andreserl][bug=][author=allenap] Use the new styling for notifications in the UI and group by category.

5750. By Blake Rouse on 2017-02-18

[r=newell-jensen][bug=1664732][author=blake-rouse] Fix pod deletion to only decompose machines that MAAS has composed. Convert pod deletion into an async operation.

MAAS know records the creation type of a machine. This type allows MAAS to know what to do upon deletion of that machine. If the machine existed in the pod or was added to the pod out of band from MAAS then it will not be decomposed when the machine or pod is deleted. If the machine was created by MAAS then it will be decomposed in the pod when the machine or pod is deleted. The pod delete operation is not an asynchronous operation where it tries its best to decompose all machines. If decomposing fails then the deletion process will be stopped and the reason for the failure will be raised. If all the machines that required decomposition are successfully decomposed then it will also delete the pre-existing machines and the pod.

5749. By Lee Trager on 2017-02-17

[r=brendan-donegan,mpontillo][bug=][author=ltrager] Fix smartctl test when running on hardware RAID and unsupported hardware.

The smartctl --scan command lists all drives on the system along with the
device type and any options needed to run smartctl against the drive. While the extra options aren't needed for a typical SCSI drive, they are needed when running smartctl on certain hardware RAID systems to indicate which drive is to be tested.

smartctl --scan also lists all drives it can find, it does not filter out
drives which do not support SMART. The script now verifies all drives support SMART before scanning.

=== modified file '.bzrignore'
--- .bzrignore	2016-09-07 15:04:32 +0000
+++ .bzrignore	2017-02-28 15:11:34 +0000
@@ -2,8 +2,10 @@
 *.egg
 *.egg-info
 *.log
+./.bzr
 ./.db.lock
 ./.failed
+./.git
 ./.hypothesis
 ./.idea
 ./.idea/libraries
@@ -11,6 +13,8 @@
 ./.idea/workspace.xml
 ./.installed.cfg
 ./.noseids
+./.run
+./.run-e2e
 ./bin
 ./build
 ./coverage
@@ -33,16 +37,10 @@
 ./media/demo/*
 ./media/development
 ./parts
-./run-e2e/*
-./run-e2e/etc/*
-./run-e2e/etc/maas/*
-./run/*
-./run/etc/*
-./run/etc/maas/*
-./run/etc/ntp/*
 ./services/*/supervise
 ./src/maasserver/static/js/enums.js
 ./TAGS
 ./tags
 ./xunit.*.xml
 dropin.cache
+__pycache__

=== modified file '.gitignore'
--- .gitignore	2016-09-07 15:04:32 +0000
+++ .gitignore	2017-02-28 15:11:34 +0000
@@ -2,8 +2,10 @@
 *.egg
 *.egg-info
 *.log
+/.bzr
 /.db.lock
 /.failed
+/.git
 /.hypothesis
 /.idea
 /.idea/libraries
@@ -11,6 +13,8 @@
 /.idea/workspace.xml
 /.installed.cfg
 /.noseids
+/.run
+/.run-e2e
 /bin
 /build
 /coverage
@@ -33,18 +37,10 @@
 /media/demo/*
 /media/development
 /parts
-/run-e2e/*
-/run-e2e/etc/*
-/run-e2e/etc/maas/*
-/run/*
-/run/etc/*
-/run/etc/maas/*
-/run/etc/ntp/*
 /services/*/supervise
 /src/maasserver/static/js/enums.js
 /TAGS
 /tags
 /xunit.*.xml
 dropin.cache
-/src/**/*.pyc
-/etc/**/*.pyc
+__pycache__

=== modified file 'HACKING.txt'
--- HACKING.txt	2016-03-28 13:54:47 +0000
+++ HACKING.txt	2017-02-28 15:11:34 +0000
@@ -108,6 +108,19 @@
    changing your locales on your workstation to ones present on the
    server will solve the issue.
 
+
+Emitting subunit
+^^^^^^^^^^^^^^^^
+
+Pass the ``--with-subunit`` flag to any of the test runners (e.g.
+``bin/test.rack``) to produce a `subunit`_ stream of test results. This
+may be useful for parallelising test runs, or to allow later analysis of
+a test run. The optional ``--subunit-fd`` flag can be used to direct the
+results to a different file descriptor, to ensure a clean stream.
+
+.. _subunit: https://launchpad.net/subunit/
+
+
 Running JavaScript tests
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -138,8 +151,9 @@
 regiond.log. To enable logging of all exceptions even exceptions where MAAS
 will return the correct HTTP status code.::
 
-    $ sudo sed -i 's/DEBUG = False/DEBUG = True/g' /usr/share/maas/maas/settings.py
-    $ sudo service maas-regiond restart
+  $ sudo sed -i 's/DEBUG = False/DEBUG = True/g' \
+  >   /usr/lib/python3/dist-packages/maasserver/djangosettings/settings.py
+  $ sudo service maas-regiond restart
 
 Run regiond in foreground
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -149,8 +163,10 @@
 placed a breakpoint into the code you want to inspect you can start the regiond
 process in the foreground.::
 
-    $ sudo service maas-regiond stop
-    $ sudo -u maas -H DJANGO_SETTINGS_MODULE=maas.settings PYTHONPATH=/usr/share/maas twistd3 --nodaemon --pidfile= maas-regiond
+  $ sudo service maas-regiond stop
+  $ sudo -u maas -H \
+  >   DJANGO_SETTINGS_MODULE=maasserver.djangosettings.settings \
+  >   twistd3 --nodaemon --pidfile= maas-regiond
 
 
 .. Note::
@@ -175,7 +191,8 @@
 Development MAAS server setup
 =============================
 
-Access to the database is configured in ``src/maas/development.py``.
+Access to the database is configured in
+``src/maasserver/djangosettings/development.py``.
 
 The ``Makefile`` or the test suite sets up a development database
 cluster inside your branch. It lives in the ``db`` directory, which

=== modified file 'MANIFEST.in'
--- MANIFEST.in	2016-12-07 12:59:10 +0000
+++ MANIFEST.in	2017-02-28 15:11:34 +0000
@@ -1,6 +1,19 @@
-graft src/maasserver/static
-graft src/maasserver/templates
-graft src/metadataserver/fixtures
-graft src/provisioningserver/templates
+<<<<<<< TREE
+graft src/maasserver/static
+graft src/maasserver/templates
+graft src/metadataserver/fixtures
+graft src/provisioningserver/templates
+=======
+graft src/maasserver/static
+graft src/maasserver/templates
+graft src/metadataserver/fixtures
+graft src/metadataserver/user_data/templates
+graft src/provisioningserver/templates
+>>>>>>> MERGE-SOURCE
 include src/maasserver/migrations/south/django16_south_maas19.tar.gz
-include src/provisioningserver/drivers/power/*.xml
+<<<<<<< TREE
+include src/provisioningserver/drivers/power/*.xml
+=======
+include src/provisioningserver/drivers/power/*.xml
+include src/metadataserver/builtin_scripts/*.template
+>>>>>>> MERGE-SOURCE

=== modified file 'Makefile'
--- Makefile	2016-10-17 06:38:56 +0000
+++ Makefile	2017-02-28 15:11:34 +0000
@@ -28,11 +28,9 @@
 
 # MAAS SASS stylesheets. The first input file (maas-styles.css) imports
 # the others, so is treated specially in the target definitions.
-scss_theme := include/nodejs/node_modules/cloud-vanilla-theme
-scss_inputs := \
-    src/maasserver/static/scss/build.scss \
-    $(wildcard src/maasserver/static/scss/*/*.scss) \
-    $(wildcard src/maasserver/static/scss/*/*/*.scss)
+scss_theme := include/nodejs/node_modules/maas-gui-vanilla-theme
+scss_input := src/maasserver/static/scss/build.scss
+scss_deps := $(wildcard src/maasserver/static/scss/_*.scss)
 scss_output := src/maasserver/static/css/build.css
 
 # Prefix commands with this when they need access to the database.
@@ -49,7 +47,7 @@
 export PGDATABASE := maas
 
 # For anything we start, we want to hint as to its root directory.
-export MAAS_ROOT := $(CURDIR)/run
+export MAAS_ROOT := $(CURDIR)/.run
 
 build: \
   bin/buildout \
@@ -61,11 +59,12 @@
   bin/twistd.region \
   bin/test.cli \
   bin/test.rack \
-  bin/test.config \
   bin/test.region \
+  bin/test.region.legacy \
   bin/test.testing \
   bin/test.js \
   bin/test.e2e \
+  bin/test.parallel \
   bin/py bin/ipy \
   $(js_enums)
 
@@ -86,12 +85,6 @@
 
 .gitignore: .bzrignore
 	sed 's:^[.]/:/:' $^ > $@
-	echo '/src/**/*.pyc' >> $@
-	echo '/etc/**/*.pyc' >> $@
-
-run/etc/ntp.conf: templates/ntp.conf
-	@mkdir -p $(@D)
-	@cp templates/ntp.conf $@
 
 configure-buildout:
 	utilities/configure-buildout
@@ -110,9 +103,14 @@
 	$(buildout) install database
 	@touch --no-create $@
 
+bin/test.parallel: \
+  bin/buildout buildout.cfg versions.cfg setup.py
+	$(buildout) install parallel-test
+	@touch --no-create $@
+
 bin/maas-region bin/twistd.region: \
     bin/buildout buildout.cfg versions.cfg setup.py \
-    $(js_enums) $(scss_output)
+    $(js_enums) $(scss_output) .run
 	$(buildout) install region
 	@touch --no-create $@
 
@@ -122,6 +120,11 @@
 	$(buildout) install region-test
 	@touch --no-create $@
 
+bin/test.region.legacy: \
+    bin/buildout buildout.cfg versions.cfg setup.py $(js_enums)
+	$(buildout) install region-test-legacy
+	@touch --no-create $@
+
 bin/maas: bin/buildout buildout.cfg versions.cfg setup.py
 	$(buildout) install cli
 	@touch --no-create $@
@@ -134,33 +137,29 @@
 	$(buildout) install js-test
 	@touch --no-create $@
 
-bin/test.e2e: bin/protractor bin/buildout buildout.cfg versions.cfg setup.py
+bin/test.e2e: \
+    bin/protractor bin/buildout buildout.cfg versions.cfg setup.py .run-e2e
 	$(buildout) install e2e-test
 	@touch --no-create $@
 
 # bin/maas-region is needed for South migration tests. bin/flake8 is
 # needed for checking lint and bin/sass is needed for checking css.
 bin/test.testing: \
-  bin/maas-region bin/flake8 bin/sass bin/buildout \
+  bin/maas-region bin/flake8 bin/sass $(scss_theme) bin/buildout \
   buildout.cfg versions.cfg setup.py
 	$(buildout) install testing-test
 	@touch --no-create $@
 
 bin/maas-rack bin/twistd.rack: \
-  bin/buildout buildout.cfg versions.cfg setup.py
+  bin/buildout buildout.cfg versions.cfg setup.py .run
 	$(buildout) install rack
 	@touch --no-create $@
 
 bin/test.rack: \
-  bin/buildout buildout.cfg versions.cfg setup.py bin/maas-rack \
-  run/etc/ntp.conf
+  bin/buildout buildout.cfg versions.cfg setup.py bin/maas-rack
 	$(buildout) install rack-test
 	@touch --no-create $@
 
-bin/test.config: bin/buildout buildout.cfg versions.cfg setup.py
-	$(buildout) install config-test
-	@touch --no-create $@
-
 bin/flake8: bin/buildout buildout.cfg versions.cfg setup.py
 	$(buildout) install flake8
 	@touch --no-create $@
@@ -211,8 +210,8 @@
 define test-scripts
   bin/test.cli
   bin/test.rack
-  bin/test.config
   bin/test.region
+  bin/test.region.legacy
   bin/test.testing
   bin/test.js
 endef
@@ -224,7 +223,10 @@
 test+lxd: lxd $(strip $(test-scripts))
 	utilities/isolated-make-test
 
-test: $(strip $(test-scripts))
+test: bin/test.parallel
+	@bin/test.parallel --subprocess-per-core
+
+test-serial: $(strip $(test-scripts))
 	@bin/maas-region makemigrations --dry-run --exit && exit 1 ||:
 	@$(RM) coverage.data .failed
 	$(foreach test,$^,$(test-template);)
@@ -239,6 +241,13 @@
 clean-failed:
 	$(RM) .noseids
 
+src/maasserver/testing/initial.maas_test.sql: bin/database syncdb
+	bin/database --preserve run -- \
+	    pg_dump maas --no-owner --no-privileges \
+	        --format=plain > $@
+
+test-initial-data: src/maasserver/testing/initial.maas_test.sql
+
 define test-template
 $(test) --with-xunit --xunit-file=xunit.$(notdir $(test)).xml || touch .failed
 endef
@@ -253,8 +262,8 @@
 	@bin/maas-region makemigrations --dry-run --exit && exit 1 ||:
 	@bin/test.rack --stop
 
-test+coverage: export NOSE_WITH_COVERAGE = 1
-test+coverage: test
+test-serial+coverage: export NOSE_WITH_COVERAGE = 1
+test-serial+coverage: test-serial
 
 coverage-report: coverage/index.html
 	sensible-browser $< > /dev/null 2>&1 &
@@ -270,10 +279,12 @@
 	    --title "MAAS r$(revno)" --directory $(@D)
 
 coverage.data:
-	@$(error Use `$(MAKE) test+coverage` to generate coverage data, \
-	    or invoke a test script using the `--with-coverage` flag)
+	@$(error Use `$(MAKE) test-serial+coverage` to generate coverage \
+            data, or invoke a test script using the `--with-coverage` flag)
 
-lint: lint-py lint-py-complexity lint-py-imports lint-js lint-doc lint-rst
+lint: \
+    lint-py lint-py-complexity lint-py-imports \
+    lint-js lint-junk lint-doc lint-rst
 
 pocketlint = $(call available,pocketlint,python-pocket-lint)
 
@@ -289,7 +300,7 @@
 lint-py: bin/flake8
 	@find $(sources) -name '*.py' \
 	  ! -path '*/migrations/*' ! -path '*/south_migrations/*' -print0 \
-	    | xargs -r0 bin/flake8 --ignore=E123,E402,E731 --isolated
+	    | xargs -r0 bin/flake8 --ignore=E123,E305,E402,E731 --isolated
 
 # Ignore tests when checking complexity. The maximum complexity ought to
 # be close to 10 but MAAS has many functions that are over that so we
@@ -300,7 +311,7 @@
 	@find $(sources) -name '*.py' \
 	  ! -path '*/migrations/*' ! -path '*/south_migrations/*' \
 	  ! -path '*/tests/*' ! -path '*/testing/*' ! -name 'testing.py' \
-	  -print0 | xargs -r0 bin/flake8 --ignore=E123,E402,E731 \
+	  -print0 | xargs -r0 bin/flake8 --ignore=E123,E305,E402,E731 \
 	              --isolated --max-complexity=$(maximum)
 
 # Statically check imports against policy.
@@ -323,6 +334,11 @@
 	    '(' -name '*.html' -o -name '*.js' ')' -print0 \
 		| xargs -r0 -n20 -P4 $(pocketlint)
 
+# Sometimes junk gets added to MAAS, like .moved files.
+lint-junk:
+	@if bzr ls --recursive --versioned | egrep '[.]moved$$'; then \
+	    echo "^ Junk found. Please remove it from the tree." >&2 ; fi
+
 # Apply automated formatting to all Python files.
 format: sources = $(wildcard *.py contrib/*.py) src templates twisted utilities etc
 format:
@@ -360,6 +376,9 @@
 man/%: docs/man/%.rst | bin/sphinx-build
 	bin/sphinx-build -b man docs man $^
 
+.run .run-e2e: run-skel
+	cp -av $^ $@
+
 enums: $(js_enums)
 
 $(js_enums): bin/py src/maasserver/utils/jsenums.py $(py_enums)
@@ -367,23 +386,23 @@
 
 styles: clean-styles $(scss_output)
 
-$(scss_output): bin/sass $(scss_theme) $(scss_inputs)
+$(scss_output): bin/sass $(scss_theme) $(scss_input) $(scss_deps)
 	bin/sass --include-path=src/maasserver/static/scss \
-	    --output-style compressed $(scss_inputs) -o $(dir $@)
+	    --output-style compressed $(scss_input) -o $(dir $@)
 
 $(scss_theme): prefix = include/nodejs
 $(scss_theme):
-	$(npm_install) --prefix $(prefix) cloud-vanilla-theme@0.0.22
+	$(npm_install) --prefix $(prefix) maas-gui-vanilla-theme@1.2.0
 
 clean-styles:
 	$(RM) $(scss_output)
 
-clean: stop clean-run clean-failed
+clean: stop clean-failed
 	find . -type f -name '*.py[co]' -print0 | xargs -r0 $(RM)
 	find . -type d -name '__pycache__' -print0 | xargs -r0 $(RM) -r
 	find . -type f -name '*~' -print0 | xargs -r0 $(RM)
 	find . -type f -name dropin.cache -print0 | xargs -r0 $(RM)
-	$(RM) -r media/demo/* media/development
+	$(RM) -r media/demo/* media/development media/development.*
 	$(RM) $(js_enums) $(js_enums).tmp
 	$(RM) src/maasserver/data/templates.py
 	$(RM) *.log
@@ -399,25 +418,10 @@
 	$(RM) tags TAGS .installed.cfg
 	$(RM) -r *.egg *.egg-info src/*.egg-info
 	$(RM) -r services/*/supervise
+	$(RM) -r .run .run-e2e
 	$(RM) xunit.*.xml
 	$(RM) .failed
 
-# Be selective about what to remove from run and run-e2e.
-define clean-run-template
-find $(1) -depth ! -type d \
-    ! -path $(1)/etc/maas/templates \
-    ! -path $(1)/etc/maas/drivers.yaml \
-    ! -path $(1)/etc/ntp/.keep \
-    ! -path $(1)/etc/ntp.conf \
-    -print0 | xargs -r0 $(RM)
-find $(1) -depth -type d \
-    -print0 | xargs -r0 rmdir --ignore-fail-on-non-empty
-endef
-
-clean-run:
-	$(call clean-run-template,run)
-	$(call clean-run-template,run-e2e)
-
 clean+db: clean
 	while fuser db --kill -TERM; do sleep 1; done
 	$(RM) -r db
@@ -427,7 +431,8 @@
 	$(warning 'distclean' is deprecated; use 'clean')
 
 harness: bin/maas-region bin/database
-	$(dbrun) bin/maas-region shell --settings=maas.demo
+	$(dbrun) bin/maas-region shell \
+	  --settings=maasserver.djangosettings.demo
 
 dbharness: bin/database
 	bin/database --preserve shell
@@ -441,7 +446,6 @@
   clean
   clean+db
   clean-failed
-  clean-run
   clean-styles
   configure-buildout
   copyright
@@ -458,6 +462,7 @@
   lint-css
   lint-doc
   lint-js
+  lint-junk
   lint-py
   lint-py-complexity
   lint-py-imports
@@ -471,10 +476,11 @@
   sudoers
   syncdb
   test
-  test+coverage
   test+lxd
   test-failed
-  test-migrations
+  test-initial-data
+  test-serial
+  test-serial+coverage
 endef
 
 #
@@ -568,13 +574,13 @@
 
 services/database/@deps: bin/database
 
-services/rackd/@deps: bin/twistd.rack
+services/rackd/@deps: bin/twistd.rack bin/maas-rack
 
 services/reloader/@deps:
 
-services/regiond/@deps: bin/maas-region
+services/regiond/@deps: bin/maas-region bin/maas-rack
 
-services/regiond2/@deps: bin/maas-region
+services/regiond2/@deps: bin/maas-region bin/maas-rack
 
 #
 # Package building
@@ -692,6 +698,28 @@
 .PHONY: $(phony) FORCE
 
 #
+# Secondary stuff.
+#
+# These are intermediate files that we want to keep around in the event
+# that they get built. By declaring them here we're also telling Make
+# that their absense is okay if a rule target is newer than the rule's
+# other prerequisites; i.e. don't build them.
+#
+# For example, converting foo.scss to foo.css might require bin/sass. If
+# foo.css is newer than foo.scss we know that we don't need to perform
+# that conversion, and hence don't need bin/sass. We declare bin/sass as
+# secondary so that Make knows this too.
+#
+
+define secondary
+  bin/py bin/buildout
+  bin/sass $(scss_theme)
+  bin/sphinx bin/sphinx-build
+endef
+
+.SECONDARY: $(sort $(strip $(secondary)))
+
+#
 # Functions.
 #
 

=== modified file 'buildout.cfg'
--- buildout.cfg	2016-10-12 15:26:17 +0000
+++ buildout.cfg	2017-02-28 15:11:34 +0000
@@ -5,10 +5,12 @@
   config-test
   coverage
   flake8
+  parallel-test
   rack
   rack-test
   region
   region-test
+  region-test-legacy
   repl
   sphinx
   testing-test
@@ -36,8 +38,8 @@
   fixtures
   hypothesis
   ipdb
+  junitxml
   nose
-  nose-progressive
   nose-timer
   postgresfixture
   python-subunit
@@ -63,17 +65,15 @@
   sys.path.sort(key=p_sys_prefix)
 environment =
   from os import environ
-  environ.setdefault("MAAS_ROOT", "${buildout:directory}/run")
+  environ.setdefault("MAAS_ROOT", "${buildout:directory}/.run")
 warnings =
   from warnings import filterwarnings
   filterwarnings("ignore", category=RuntimeWarning, module="pkg_resources")
 inject-test-options =
-  # When running tests from a console use the progressive output plugin.
-  # When running headless increase the verbosity so we can see the test
-  # being run from a log file. An `options` list must be defined ahead
-  # of the use of this snippet.
-  # *** NOSE PROGRESSIVE IS BROKEN IN PYTHON 3.5 ***
-  # ["--verbosity=0", "--with-progressive"]
+  # When running tests from a console show only dots, but when running
+  # headless increase verbosity so we can see the test being run from a
+  # log file. An `options` list must be defined ahead of the use of this
+  # snippet.
   options += (
     ["--verbosity=1"]
     if sys.stdout.isatty() else
@@ -92,6 +92,16 @@
 entry-points = database=postgresfixture.main:main
 scripts = database
 
+[parallel-test]
+recipe = zc.recipe.egg
+eggs =
+  ${common:test-eggs}
+entry-points =
+  test.parallel=maastesting.parallel:main
+scripts = test.parallel
+extra-paths =
+  ${common:extra-paths}
+
 [region]
 recipe = zc.recipe.egg
 test-eggs =
@@ -104,7 +114,7 @@
   twistd.region=twisted.scripts.twistd:run
 initialization =
   ${common:initialization}
-  environ.setdefault("DJANGO_SETTINGS_MODULE", "maas.development")
+  environ.setdefault("DJANGO_SETTINGS_MODULE", "maasserver.djangosettings.development")
 scripts =
   maas-region
   twistd.region
@@ -115,8 +125,54 @@
 recipe = zc.recipe.egg
 eggs =
   ${region:eggs}
-entry-points =
-  test.region=maasserver:execute_from_command_line
+  ${common:test-eggs}
+entry-points =
+  test.region=maastesting.noseplug:main
+initialization =
+  ${region:initialization}
+  options = [
+    "--with-crochet",
+    "--with-resources",
+    "--with-scenarios",
+    "--with-select",
+    "--select-dir=src/maasserver",
+    "--select-dir=src/metadataserver",
+    "--cover-package=maas,maasserver,metadataserver",
+    "--cover-branches",
+    # Reduce the logging level to INFO here as
+    # DebuggingLoggerMiddleware logs the content of all the
+    # requests at DEBUG level: we don't want this in the
+    # tests as it's too verbose.
+    "--logging-level=INFO",
+    "--logging-clear-handlers",
+    # Do not run tests tagged "legacy".
+    "-a", "!legacy",
+  ]
+  ${common:inject-test-options}
+  # Configure logging. TODO: Do this in a plugin.
+  from provisioningserver import logger
+  logger.configure(mode=logger.LoggingMode.COMMAND)
+  # Limit concurrency in all thread-pools to ONE.
+  from maasserver.utils import threads
+  threads.install_default_pool(maxthreads=1)
+  threads.install_database_unpool(maxthreads=1)
+  # Disable all database connections in the reactor.
+  from maasserver.utils import orm
+  from twisted.internet import reactor
+  assert not reactor.running, "The reactor has been started too early."
+  reactor.callFromThread(orm.disable_all_database_connections)
+  # Last and least, configure Django.
+  import django; django.setup()
+scripts = test.region
+extra-paths =
+  ${region:extra-paths}
+
+[region-test-legacy]
+recipe = zc.recipe.egg
+eggs =
+  ${region:eggs}
+entry-points =
+  test.region.legacy=maasserver:execute_from_command_line
 initialization =
   ${region:initialization}
   environ.setdefault("MAAS_PREVENT_MIGRATIONS", "1")
@@ -124,12 +180,8 @@
     "test",
     "--noinput",
     "--with-crochet",
-    # Disable resources in the region for now because of suspected bad
-    # interactions with django_nose.
-    # "--with-resources",
     "--with-scenarios",
     "--with-select",
-    "--select-dir=src/maas",
     "--select-dir=src/maasserver",
     "--select-dir=src/metadataserver",
     "--cover-package=maas,maasserver,metadataserver",
@@ -140,9 +192,11 @@
     # tests as it's too verbose.
     "--logging-level=INFO",
     "--logging-clear-handlers",
+    # Run only tests tagged "legacy".
+    "-a", "legacy",
   ]
   ${common:inject-test-options}
-scripts = test.region
+scripts = test.region.legacy
 extra-paths =
   ${region:extra-paths}
 
@@ -258,27 +312,6 @@
 scripts =
   test.rack
 
-[config-test]
-recipe = zc.recipe.egg
-eggs =
-  ${common:test-eggs}
-entry-points =
-  test.config=maastesting.noseplug:main
-initialization =
-  ${common:initialization}
-  options = [
-    "--with-resources",
-    "--with-scenarios",
-    "--with-select",
-    "--select-dir=etc/maas/templates/commissioning-user-data",
-    "--cover-package=snippets",
-    "--cover-branches",
-  ]
-  ${common:inject-test-options}
-extra-paths = ${common:extra-paths}
-scripts =
-  test.config
-
 [e2e-test]
 recipe = zc.recipe.egg
 eggs =
@@ -293,8 +326,8 @@
   ${common:path-munge}
   from os import environ
   environ.setdefault("MAAS_RACK_DEVELOP", "TRUE")
-  environ.setdefault("MAAS_ROOT", "${buildout:directory}/run-e2e")
-  environ.setdefault("DJANGO_SETTINGS_MODULE", "maas.development")
+  environ.setdefault("MAAS_ROOT", "${buildout:directory}/.run-e2e")
+  environ.setdefault("DJANGO_SETTINGS_MODULE", "maasserver.djangosettings.development")
   environ.setdefault("DEV_DB_NAME", "test_maas_e2e")
   environ.setdefault("MAAS_PREVENT_MIGRATIONS", "1")
 

=== modified file 'docs/_templates/maas/static/css/main.css'
--- docs/_templates/maas/static/css/main.css	2014-06-09 16:25:19 +0000
+++ docs/_templates/maas/static/css/main.css	2017-02-28 15:11:34 +0000
@@ -73,3 +73,17 @@
   text-decoration: none;
   border-bottom: 1px solid #6D4100;
 }
+
+/*
+ * Custom CSS selectors for the API documentation page.
+ *
+ * Make subtitles for each API endpoint smaller, so they don't overwhelm
+ * the remainder of the documentation.
+ */
+div#maas-api div#operations h4 code.docutils {
+  font-size: 75%;
+}
+
+div#maas-api div#operations div.section h5 {
+  font-size: 90%;
+}

=== removed file 'docs/about.rst'
--- docs/about.rst	2016-04-11 16:23:26 +0000
+++ docs/about.rst	1970-01-01 00:00:00 +0000
@@ -1,50 +0,0 @@
-About this documentation
-========================
-
-This is the documentation for Canonical's MAAS software. If you aren't
-sure what that is, you should probably skip everything else and head
-straight to the :ref:`orientation` section where it is explained.
-Like any software though, it can be frustrating if you don't know how
-bits of it work, how to achieve certain goals or what to do when
-things go wrong. Amongst its various sections, this manual aims to
-answer all those questions and plenty more you haven't even thought of
-yet.
-
-
-Getting it
-----------
-
-In a cunning move, the current documentation always lives, and is
-built from, the main MAAS source code (in the top-level ``docs/``
-directory). That means that whatever MAAS package you have installed,
-or even if you are really living life on the edge and have checked out
-a development version from Launchpad, this documentation should be the
-latest and most appropriate version for the software you are running.
-However, it is also possible that there have been additional sections,
-or more helpful and clearer bits added since the package you are using
-was made. For this reason you can always find the latest documentation
-online here: `http://maas.io/`_.
-
-.. _http://maas.io/:
-  http://maas.io
-
-
-Contributing
-------------
-
-If you have some extra information to add, or think you have spotted
-an error or something out of date, we really want to hear about
-it.  Please `File a bug report`_ or `contact us directly`_.  In addition
-you can talk to us on the Freenode IRC channel #maas.
-
-.. _File a bug report:
-  https://bugs.launchpad.net/maas/+filebug
-
-.. _contact us directly:
-  https://launchpad.net/~maas-maintainers/+contactuser
-
-If you see something wrong with this documentation, you can help us fix it.
-Download the source to MAAS by following the instructions in
-:doc:`the hacking guide <hacking>`, make your changes, and propose a merge
-against lp:maas on Launchpad.  The documentation source lives in the top-level
-``docs/`` directory.

=== removed file 'docs/bootsources.rst'
--- docs/bootsources.rst	2016-09-27 22:26:08 +0000
+++ docs/bootsources.rst	1970-01-01 00:00:00 +0000
@@ -1,113 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _bootsources:
-
-Boot images import configuration
-================================
-
-The configuration for where a region downloads its images is defined by
-a set of "sources".  Each "source" defines a Simplestreams repository
-location (``url``) from which images can be downloaded and a
-``keyring_filename`` (or ``keyring_data``) for validating index and image
-signatures from that location.  For each source, you can define a series of
-filters (``selections``) specifying which images should be downloaded from
-that source.
-
-The following example use the MAAS CLI to list the boot sources and the boot
-source selections.  Assuming the CLI ``PROFILE`` is the name of the profile
-under which you're logged in to the server::
-
-    $ maas $PROFILE boot-sources read
-    [
-        {
-            "url": "http://images.maas.io/ephemeral-v3/daily/",
-            "keyring_data": "",
-            "resource_uri": "<url omitted for readability>",
-            "keyring_filename": "/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg",
-            "id": 1
-        }
-    ]
-
-    $ maas $PROFILE boot-source-selections read 1
-    [
-        {
-            "labels": [
-                "release"
-            ],
-            "arches": [
-                "amd64"
-            ],
-            "subarches": [
-                "*"
-            ],
-            "release": "trusty",
-            "id": 1,
-            "resource_uri": "<url omitted for readability>"
-        }
-    ]
-
-
-Restricting the images being downloaded
----------------------------------------
-
-Let's say you want to add a previous LTS release to images being downloaded.
-Starting from the configuration described above, you would need to:
-
-- Add the "Precise" selection (the selection '1' of the source '1')::
-
-    $ maas $PROFILE boot-source-selections create 1 os="ubuntu" release="precise" arches="amd64" subarches="*" labels="*"
-
-After you've selected the additional boot sources you need to tell MAAS to
-start the import process by running the command::
-
-    $ maas $PROFILE boot-resources import
-
-Downloading the images from a different source
-----------------------------------------------
-
-Let's say you want to import the images from a different location.  You would
-need to to change the source's url and keyring::
-
-    $ maas $PROFILE boot-source update 1 url="http://custom.url" keyring_filename="" keyring_data@=./custom_keyring_file
-    {
-        "url": "http://custom.url/",
-        "keyring_data": "<base64 encoded content of `custom_keyring_file`>",
-        "resource_uri": "<url omitted for readability>",
-        "keyring_filename": "",
-        "id": 1
-    }
-
-Adding a source
----------------
-
-You can also add a new source::
-
-    $ maas $PROFILE boot-sources create url=http://my.url keyring_filename="" keyring_data@=./ custom_keyring_file
-    {
-        "url": "http://my.url/",
-        "keyring_data": "ZW1wdHkK",
-        "keyring_filename": "",
-        "id": 2,
-        "resource_uri": "<url omitted for readability>"
-    }
-
-Inside that newly created source ('2') you can add selections::
-
-    $ maas $PROFILE boot-source-selections create 2 os="ubuntu" release="trusty" arches="amd64" subarches="*" labels='*'
-    {
-        "labels": ["*"],
-        "arches": ["amd64"],
-        "subarches": ["*"],
-        "release": "trusty",
-        "id": 3,
-        "resource_uri": "<url omitted for readability>"
-    }
-
-Deleting a source
------------------
-
-Let's say you need to delete the newly added source.
-
-To delete the source::
-
-    $ maas $PROFILE boot-source delete 2

=== modified file 'docs/changelog.rst'
--- docs/changelog.rst	2017-02-17 05:59:11 +0000
+++ docs/changelog.rst	2017-02-28 15:11:34 +0000
@@ -2,6 +2,7 @@
 Changelog
 =========
 
+<<<<<<< TREE
 2.1.4
 =====
 
@@ -170,881 +171,105 @@
 
 2.1.0
 =====
+=======
+2.2.0 (beta1)
+=============
+>>>>>>> MERGE-SOURCE
 
 Important announcements
 -----------------------
 
-**New MAAS dashboard, now including discovered devices!**
- In MAAS 2.1, administrators will be redirected to the new MAAS dashboard
- after they log in to the Web UI. On the dashboard, administrators are guided
- through where to go to quickly get MAAS up and running. In addition,
- administrators can view hosts that have been discovered on the network, and
- quickly convert them to a device in MAAS.
-
-**Image streams have been upgraded to v3. (Important: update your mirrors!)**
- In order to support the new kernels, MAAS has moved to a new format for image
- streams. Previous releases used stream in “v2” format. Starting from MAAS 2.1,
- the “v3” format image stream will be used.
-
- Users upgrading from earlier versions of MAAS who are using the default images
- URL will be automatically migrated to the new “v3” URL.
-
- For users with custom mirrors, MAAS will not migrate the image URL
- automatically. Users must ensure their image mirrors contain the “v3” stream,
- which is available at http://images.maas.io/ephemeral-v3/. Old images
- downloaded from the “v2” stream will continue to work until the mirror is
- updated, but the MAAS team only supports MAAS 2.1 users using the “v3” stream.
- Please note that bootloaders are now included in the mirror; be sure to mirror
- them in addition to the images.
-
-**New hardware enablement kernel naming convention**
- Starting from MAAS 2.1 and Ubuntu 16.04 "Xenial", MAAS is adhering to a new
- naming convention for hardware enablement kernels. On Xenial and above, MAAS
- will not support HWE kernels with the old naming convention, but it will
- support HWE kernel channel. For example, given Ubuntu 16.04 "Xenial" and
- Yakkety, currently available kernels in MAAS are:
-
-  * ga-<version>
-    The GA, or general availability kernel is the kernel which the Ubuntu
-    release shipped with. For example ‘ga-16.04’ is the default 4.4 kernel
-    which shipped on Ubuntu 16.04 "Xenial". The ga kernel contains all bug and
-    security fixes provided by the Ubuntu archives. Deployments which use the
-    ga kernel will stay at the same kernel version through upgrades until the
-    entire release is upgraded with ‘do-release-upgrade.’
-
-  * hwe-<version>
-    The latest Hardware Enablement Kernel currently available in a given
-    Ubuntu release. As new Hardware Enable Kernels are released with new Ubuntu
-    releases the hwe-<version> kernel will be upgraded up until the next LTS.
-    For example hwe-16.04 is currently the 16.04 GA kernel. Once 16.10 is
-    released the hwe-16.04 kernel will be upgraded to the 16.10 GA kernel. The
-    kernel will continue to be upgraded up until and including the 18.04 GA
-    kernel.
-
-**Commissioning-user-data and pxe/uefi templates no longer available**
- In the past, MAAS stored commissioning-user-data and pxe/uefi templates in
- /etc/maas/templates. As of MAAS 2.1, these templates are no longer available
- under /etc/maas.
-
-Major new features
-------------------
-
-**First user configuration journey (UI)**
- MAAS now provides the ability for administrators to perform some initial
- configuration immediately after they log-in into the MAAS UI for the first
- time. The configuration includes:
-
-  * Ability to change the name of your MAAS
-  * Ability to configure options that affect connectivity:
-    * Option to select an Upstream DNS Server (Optional)
-    * Option to input different Ubuntu Mirrors (Required)
-    * Option to input an external proxy (Optional)
-  * Ability to select additional images to download
-  * Ability to import SSH keys from Launchpad or Github
-
-**Device discovery**
- MAAS will now automatically listen to the network and report any discovered
- devices. Devices are identified when the MAAS rack observes them
- communicating on an attached IPv4 subnet. Discovered devices that do not
- correspond to machines and devices already known to MAAS are shown on the
- dashboard. If a device advertises a hostname using mDNS (such as with avahi
- or Bonjour), MAAS will also present the discovered hostname in the dashboard.
- Using the dashboard, a discovery can quickly be added to MAAS as a device or
- as a network interface to a machine or device.
-
-**Active subnet mapping**
- The device discovery feature was designed to operate passively by default.
- While MAAS will not send any traffic on attached networks for discovery
- purposes unless instructed to, there are two ways to instruct MAAS to map
- your networks:
-
-  * On-demand: administrators can choose to map their subnet using an action
-    on the subnet details page. This action will scan the subnet just once, so
-    that observed devices on that subnet may quickly be seen in the dashboard.
-    This feature is useful after initially installing MAAS, to quickly populate
-    the list of discoveries with active devices on the network.
-
-  * Periodically (recommended): by enabling active discovery on a per-subnet
-    basis, subnets will be scanned at a user-specified interval. (default is
-    every three hours) This allows MAAS to maintain current information about
-    which IP addresses are in use on each subnet.
-
- Before actively mapping any networks, it is recommended that the ‘nmap’
- package be installed on each MAAS rack controller. Doing so results in faster
- scans that require less network traffic. (If ‘nmap’ is not installed, MAAS
- will resort to scanning using the ‘ping’ utility.)
-
-**Offline deployment and customizable APT repositories**
- MAAS 2.1 improves its offline deployment capabilities by adding support for
- Ubuntu derived repositories, PPAs, and custom APT repositories. This enables
- MAAS to configure deployed machines with the correct APT repositories and
- keyrings, without being dependent on Internet connectivity.
-
-  * Ubuntu Derived Repositories (from an Ubuntu Mirror)
-    MAAS 2.0 and earlier versions only allowed users to change the Ubuntu
-    archive to use. This was limited to defining the location of an official
-    Ubuntu mirror.
-
-    Derived repositories are based on an Ubuntu mirror, but have had packages
-    added or removed, which requires signing the repository with an unofficial
-    GPG key. MAAS now allow users to provide GPG key fingerprints to support
-    this type of repository. These fingerprints are required in order for
-    the derived repository to be trusted, and will be added to the APT keyring
-    on each machine.
-
-  * PPAs
-    PPAs can now be specified, which will be added to the APT sources on
-    deployed machines. Users may define a GPG key fingerprint in order for
-    the machine to trust the PPA, for cases where the deployed machine cannot
-    access the Ubuntu key server.
-
-  * Custom repositories
-    Custom repositories can be specified to add additional packages to deployed
-    machines. For custom repositories, the distribution and component can be
-    customized as appropriate. For example, users would be able to add the
-    Google Chrome repository, which is as follows:
-
-    deb http://dl.google.com/linux/chrome/deb/ stable main
-
-    In this case, the distribution is “stable”, and the component is “main”.
-    (Multiple components may also be specified.)
-
-**MAAS time sync, NTP services and configuration**
- MAAS now provides managed NTP services (with ntpd) for all region and rack
- controllers. This allows MAAS to both keep its own controllers synchronized,
- and keep deployed machines synchronized well.
-
-  * Region controllers synchronize time externally
-    The MAAS region controller configures the NTP service (ntpd) to keep its
-    time synchronized from one or more external sources. By default, the MAAS
-    region controller uses ntp.ubuntu.com. This can be customized on the
-    settings page.
-
-  * Rack controllers synchronize time from the region controller
-    The rack controllers also configure the NTP service (ntpd). Unlike the
-    region controllers, rack controllers synchronize their time from region
-    controllers, rather than accessing an external time source.
-
-    Rack controllers also configure DHCP with the correct NTP information, so
-    that any machine on the network that obtains a DHCP lease from MAAS will
-    benefit from the enhanced NTP support.
-
-  * Controllers and Machines can synchronize time for external time sources only.
-    MAAS 2.1 also provides the ability to directly use external time sources
-    without using the Rack Controller as a source of time for machines. This
-    means that administrators who already have their own NTP infrastructure,
-    and they don’t want MAAS to provide NTP services, they can tell all
-    machines and controllers to sync their time from the external time source.
-    This can be done by selecting the "External Only" option on the Settings
-    page.
-
-**Advanced networking: static routes**
- MAAS 2.1 introduces the ability to define static routes. This allows
- administrators to configure reachability to a subnet from a source subnet.
- Administrators can define routes on a per-subnet basis to use a particular
- gateway, using a configured destination and metric.
-
-**Machine networking: bridge configuration**
- MAAS now supports the creation of bridge interfaces. This support is limited
- to the ability to create a bridge against a single interface, such as for the
- purpose of eventually deploying virtual machines or containers on the machine.
-
- Automatic bridge creation on all configured interfaces can also be performed
- at allocation time using the API.
-
-**Rescue mode**
- MAAS 2.1 supports a new state in the machine lifecycle: rescue mode. Rescue
- mode allows users to boot a Deployed or a Broken using an ephemeral image.
- (That is, Ubuntu is running in memory on the machine.) This allows
- administrators to SSH to the machine for maintenance purposes, similar to
- running Ubuntu from a USB stick.
-
-**Enhanced images user interface**
- The MAAS images page has been completely redesigned. Improvements include:
-
-  * Supports selecting the image source (maas.io or custom repository).
-  * Now shows the image releases and architectures available in a repository before the import starts.
-  * Now displays detailed status throughout the image import process.
-  * The Boot Images section in the settings page has been removed.
-
-Minor new features
-------------------
-
-**Disk erasing improvements and secure erase**
- In 1.7 (and later) MAAS introduced the ability to erase disks on machine
- release. This support was limited to erasing the whole disk and could only
- be enabled (or disabled) globally.
-
- Starting from MAAS 2.1, it now supports the ability to request disk erasure
- on a per-machine basis, at the time the machine is released. In addition, new
- options for the disk erase mode have been added:
-
-  * Secure erase - If this option is enabled, MAAS will attempt to erase via
-    secure erase (if the storage device support it), otherwise, it will perform
-    a full erase or a quick erase (depending on the options provided).
-
-  * Quick erase - If this option is enabled, MAAS will only erase the beginning
-    and the end of each storage device.
-
-**Machine networking: - SR-IOV auto-tagging, tags UI**
- MAAS now allows the definition of tags per network interface via the WebUI.
- Additionally, MAAS also attempts to auto-detect and tag SR-IOV NIC cards.
-
-**Support for low latency kernels**
- Starting from Ubuntu 16.04 “Xenial” and later, “low latency” kernels available
- on i386 and amd64 for both GA and HWE kernels. The currently available
- lowlatency kernels are:
-
-  * hwe-x-lowlatency - For using the Xenial Lowlatency kernel on Trusty
-  * ga-16.04-lowlatency - For using the GA lowlatency kernel on Xenial
-  * hwe-16.04-lowlatency - For using the HWE lowlatency kernel on Xenial.
-
-**Bootloaders are now provided in the image stream**
- Previously, bootloaders where downloaded on the rack controller from the
- Ubuntu archives for each architecture MAAS had images for. Starting from MAAS
- 2.1, bootloaders are downloaded with the images. All rack controllers retrieve
- all supported bootloaders from the region controller. MAAS no longer directly
- interacts with the Ubuntu archives.
-
- In the case that bootloaders are missing from the stream, MAAS will attempt
- to locate previous downloads of the bootloader as well as package installs of
- the bootloader. Users with image mirrors must ensure image their mirrors
- include the bootloaders in order to be running the latest supported versions.
-
-**SSH keys can be imported from Launchpad or GitHub**
- All users will now have the ability to import their SSH public keys from the
- UI. Users who log-in to MAAS for the first time will be prompted to import
- their SSH keys, if desired. Alternatively, users can import keys later on
- their user profile page, or continue to upload keys manually.
-
-Other notable changes
----------------------
-
-**Better error surfacing for DHCP snippets and package repositories**
- Both the DHCP Snippets section and the Package Repositories section have been
- improved in order to show errors in a more user-friendly way.
-
-**Vanilla framework: HTML and CSS updates, smoother look and feel**
- The HTML templates and CSS frameworks in MAAS have been completely rebuilt
- with the Vanilla CSS framework. Icons and interactions in MAAS have greatly
- improved; users will notice smoother, more intuitive interactions with the UI.
-
- The MAAS team would like to thank the Canonical design and web teams for their
- contributions in this area.
-
-Issues fixed in this release
-----------------------------
-
-A full list of issues fixed in this release is available in the Launchpad 2.1.0
-Milestone page
-
-  https://launchpad.net/maas/+milestone/2.1.0
-
-
-2.1.0 (RC1)
-===========
-
-Issues fixed in this release
-----------------------------
-
-LP: #1569365    TestPartition.test_get_partition_number_returns_starting_at_2_for_ppc64el fails spuriously
-
-LP: #1598470    "Deployed" and "Deploying" are too similar
-
-LP: #1536354    Users' maas api keys do not have a name
-
-LP: #1631358    [2.1] Incorrect logging message - showing SERVICE_STATE.ON
-
-LP: #1631420    [2.1 UI] Images page "Queued for download" is confusing when selections are not saved
-
-LP: #1631024    [2.1b1] Dashboard column widths for discovered items are wonky
-
-LP: #1631022    [2.1b1] 'Registering existing rack controller'
-
-LP: #1629604    [2.1] Command 'interface link-subnet' does not work
-
-LP: #1628114    [FUJ] SSH input field not indicated for invalid username & the error is incomprehensible
-
-LP: #1629475    [2.1 ipv6] DHCP generation should not fail when address-family conflicts are present
-
-LP: #1603466    [2.0rc2] Commissioning node with gateway_link_v4 set fails.
-
-LP: #1608555    [2.1, 2.0 UI] Error when using dhcp range with pre-existing dynamic reservation
-
-LP: #1632815    [2.1b2] Node failed to be released, because of the following error: 'NoneType' object has no attribute 'addErrback'
-
-LP: #1632395    [2.1, Yakkety, UI] UI error when adding a chassis
-
-LP: #1631079    [2.0, 2.1 UI] Other reserved IP ranges disappear when one of them is deleted on Subnet details page.
-
-LP: #1630667    [2.1b1] MAAS fails to deploy systems with 3+ TB disks
-
-LP: #1630633    [2.1 Yakkety UI] Unable to select nodes
-
-LP: #1629061    [2.0, 2.1] Release and list IPs reserved by another user
-
-LP: #1605476    [2.0rc2] Changing DNSSEC validation does not trigger configuration file update
-
-
-2.1.0 (beta2)
-=============
-
-Issues fixed in this release
-----------------------------
-
-LP: #1630394    [2.1] Bootloaders not downloaded on initial import
-
-LP: #1611949    cryptic error when PXE-boot requires an image not yet imported
-
-LP: #1625676    [2.0, 2.1, UI] MAAS webui allows boot disk to be changed on an already deployed node
-
-LP: #1630591    Rename "Networks" tab to "Subnets"
-
-LP: #1628761    [2.1] netaddr assumes MAC OUI is ascii
-
-LP: #1619262    [2.1, 2.0] Can't input dynamic range on "Enable DHCP" after I deleted the dynamic range
-
-LP: #1630636    [2.1 ipv6] YAML error when maas_url has an IPv6 IP
-
-LP: #1612203    Machine unable to pxe with no-such-image while non-related images are being imported
-
-LP: #1628645    External DHCP detection is broken for a variety of reasons
-
-LP: #1627362    [2.1] expected string or bytes-like object
-
-LP: #1614659    [2.1] When trying to release a node, it gets stuck in releasing if there is no rack controller to power control
-
-LP: #1445941    WebUI needs a filter for deployed OS
-
-
-2.1.0 (beta1)
-=============
-
-Important Announcements
------------------------
-
-**New Hardware Enablement Kernels naming convention**
- Starting from MAAS 2.1 and Ubuntu Xenial, MAAS is adhering to a new naming
- convention for hardware enablement kernels. On Xenial and above, MAAS will
- not support HWE kernels with the old naming convention, but it will support
- HWE kernel channel. For Ubuntu Xenial and Yakkety, currently available
- kernels in MAAS now are:
-
- * ga-<version>
-   The GA, or general availability kernel is the kernel which the Ubuntu
-   release shipped with. For example ‘ga-16.04’ is the default 4.4 kernel
-   which shipped on Ubuntu Xenial. The ga kernel contains all bug and security
-   fixes provided by the Ubuntu archives. Deployments which use the ga
-   kernel will stay at the same kernel version through upgrades until the
-   entire release is upgraded with ‘do-release-upgrade.’
-
- * hwe-<version>
-   The latest Hardware Enablement Kernel currently available in a given
-   Ubuntu release. As new Hardware Enable Kernels are released with new
-   Ubuntu releases the hwe-<version> kernel will be upgraded up until the
-   next LTS. For example hwe-16.04 is currently the 16.04 GA kernel. Once
-   16.10 is released the hwe-16.04 kernel will be upgraded to the 16.10 GA
-   kernel. The kernel will continue to be upgraded up until and including
-   the 18.04 GA kernel.
-
-**New Simplestreams Version - Update your images & your Image repositories**
- In order to support the new kernels, MAAS has updated the version of the
- MAAS Image streams. Previously MAAS has been using the Streams Version 2,
- and as of MAAS 2.1 it will use the MAAS Streams Version 3.
-
- All users who upgrade from an earlier version of MAAS who have been using
- the default image mirror, will be automatically migrated to the new version
- of streams.
-
- For all those users running a custom mirror, MAAS won’t make the migration
- automatically. Users are requested to update their image mirror to match the
- latest images. This image mirror is now available at
- http://images.maas.io/ephemeral-v3/.
-
-Major new features
-------------------
-
-**Support for Low Latency kernels.**
- Starting from MAAS 2.1 Beta 1 and Ubuntu Xenial, MAAS will be making available
- the ability to install low latency kernels. Low latency kernels are available
- on i386 and amd64 for both GA and HWE kernels. The currently available
- lowlatency kernels are
-
-  * hwe-x-lowlatency - For using the Xenial Lowlatency kernel on Trusty
-  * ga-16.04-lowlatency - For using the GA lowlatency kernel on Xenial
-  * hwe-16.04-lowlatency - For using the HWE lowlatency kernel on Xenial.
-
-**Bootloaders are now provided in the SimpleStream.**
- Previously bootloaders where downloaded on the Rack Controller from the Ubuntu
- archives for each architecture MAAS had images for. Starting with MAAS 2.1
- Beta 1 bootloaders are downloaded with the images from the SimpleStream. All
- Rack Controllers retrieve all supported bootloaders from the Region Controller.
- MAAS no longer directly interacts with the Ubuntu archives.
-
- In the case that bootloaders are missing from the SimpleStream MAAS will
- attempt to locate previous downloads of the bootloader as well as package
- installs of the bootloader.
-
-Minor new features
-------------------
-
-**Active Device Discovery - Map your subnet**
- To complete MAAS’ Active Discovery, starting from beta 1 MAAS 2.1 now allows
- the user to ‘Map a subnet’, both automatically at regular intervals, or
- manually:
-
-  * Manually
-    Administrators can now Map a subnet manually from the Subnet Details page
-    under the ‘Take Action’ option. This will allow administrators to map
-    their subnet. By default, this will use ping but if nmap is installed,
-    it will automatically use nmap.
-
-  * Automatically
-    Administrators can now chose to Map their subnets Automatically at regular
-    intervals. This allows administrators to have MAAS always probe on the
-    network to find new devices. By default, the automatic mechanism is enabled,
-    but no subnet is enabled by default.
-
- To automatically map each subnet, please refer to the ‘Active Discovery’
- section on the subnet details page.
-
-Bugs fixed in this release
---------------------------
-
-LP: #1392763    When changing sync-url via the UI, it's not obvious if syncing starts on its own or not
-LP: #1508975    maas deletes products/images locally that do not exist remotely
-LP: #1481285    1.8 Boot images tick boxes should be orange
-LP: #1629402    [2.1] please cleanup log format for new interface monitoring state
-LP: #1629011    Missing punctuation in disk erasing options
-LP: #1629008    Missing preposition sentence disk erasing options
-LP: #1629004    Typo: "futher"
-LP: #1628052    [2.1, FUJ] Help text in input fields is missing 'e.g'
-LP: #1459888    Too much spacing between checkboxes/releases in the 'Images'
-LP: #1627039    [2.1] Discovery object and view doesn't set a flag when the device is the DHCP server
-LP: #1627038    [2.1] SSH key import should use the specified HTTP proxy if one exists
-LP: #1625714    DHCP services on rack controllers only publishes external NTP servers
-LP: #1625711    Peer selection for NTP servers on region controllers is broken
-LP: #1593388    Changing a boot source URL while images are being download doesn't interrupt current downloads to use the new URL
-LP: #1623878    [2.1] mDNS label contains disallowed characters
-LP: #1394792    MAAS could do a better job of reporting image download status
-LP: #1623110    [2.1] Networks page doesn't load fully on yakkety
-LP: #1629896    [2.1] Deployment defaulting to hwe-16.04 instead of ga-16.04
-LP: #1629491    [2.1] After upgrade to latest trunk (pre-beta1) and after updating images, machines fail to pxe boot due to missing hwe-x kernel
-LP: #1629142    2.1 DHCP reported as enabled but not running
-LP: #1629045    [2.1] When failing to download images, MAAS leaves old files in the fs
-LP: #1629022    [2.1, UI] Broken 'images page' link
-LP: #1629019    [2.1 ipv6] log_host needs to be ipv6 when booting ipv6-only
-LP: #1628298    [2.1 UI] SSH keys not listed on user page and no button to add keys
-LP: #1628213    [2.1 yakkety UI] First user journey doesn't display and can't be skipped
-LP: #1627363    [2.1] 'NoneType' object has no attribute 'external_dhcp'
-LP: #1627019    [2.1, rev5385] NTP services on region/rack keep showing as ON/OFF constantly
-LP: #1623634    [2.1, UX] Trying to cancel an image import from the new Images page results on it not being cancelled on the backend.
-LP: #1589640    [2.0b6] MAAS should validate a boot source path actually provides images
-
-Known issues and workarounds
-Trusty images not available on fresh installs
-The MAAS Images V3 streams do not yet have Ubuntu Trusty available. These are currently being built to be made available.
-
-User’s upgrading from a previous version of MAAS that had originally imported Trusty images will continue to be able to deploy Trusty. Once the images are made available, MAAS will automatically update (if so configured).
-
-LP: #1627362 - expected string or bytes-like object
-In some situations after an upgrade, accessing the dashboard might yield error above. This is a difficult to easily reproduce issue. If you come across it please contact a MAAS developer immediately.
-
-https://bugs.launchpad.net/maas/+bug/1627362
-
-
-2.1.0 (alpha4)
-==============
-
-Important Announcements
------------------------
-
-**MAAS Landing page - Let’s see what’s on your network!**
- As of MAAS 2.1 alpha 4, administrative users have a new landing page. Once
- administrators log in they will be redirected to the MAAS dashboard.
-
- This dashboard is where administrators will have some basic information
- and the ability to see the observed and discovered devices.
-
-Major new features
-------------------
-
-**Device discovery UI**
- MAAS 2.1 alpha 4 introduces the MAAS Device Discovery UI. As part of the
- dashboard, administrative users will be able to see all the observed and
- discovered devices.
-
- MAAS will also allow administrator to properly register those discoveries
- as MAAS known devices, and be able to select the IP address allocation for
- them, if MAAS is to manage them.
-
-**Active Device Discovery - map your network (API only)**
- As of MAAS 2.1 alpha 2, networks attached to rack controllers are observed
- for device discovery purposes. MAAS listens to ARP requests and replies to
- determine which IPv4 addresses are in-use on attached networks, and will
- resolve their hostnames if possible (when advertised using the mDNS
- protocol).
-
- As of MAAS 2.1 alpha 4, MAAS now has the ability to actively probe subnets.
- This allows MAAS to keep its knowledge of which devices are on the network
- up-to-date, and discover “quiet” devices that MAAS would not be able to
- observe passively. If ‘nmap’ is installed, MAAS will prefer to use it for
- scanning (since the scan is faster and will transmit fewer packets). If
- ‘nmap’ is not installed, MAAS will fall back to using parallel ‘ping’ requests.
-
- Scanning is available using the API at the following URL:
-
-    POST /MAAS/api/2.0/discovery/?op=scan
-
- To scan using the command-line interface, you can use the following syntax:
-
-    maas <profile> discoveries scan [cidr=<cidr> [cidr=<cidr>....] [force=true] [always_use_ping=true] [slow=true] [threads=<num-concurrent-scanning-threads>]
-
- If you want to scan particular subnets, specify one or more using the cidr
- option. For example, ‘cidr=192.168.0.0/24’ would scan for neighbours on
- 192.168.0.0/24 on any rack controller configured with an address in that
- network. The cidr option can be specified multiple times, such as
- ‘cidr=192.168.0.0/24 cidr=192.168.1.0/24’.
-
- If you want to scan all networks attached to all rack controllers, you must
- specify the “force=true” option. (This is not allowed by default, since some
- network operators do not allow active neighbour scanning.)
-
- If your organization has a policy against using ‘nmap’, you will want to use
- the ‘always_use_ping’ option, in case ‘nmap’ has been installed on a rack
- controller by mistake.
-
- If quickly scanning your network using ‘nmap’ may raise alerts with an
- intrusion detection system, you can use the ‘slow=true’ argument to slow
- down scanning. This option has no effect when using ‘ping’, since scanning
- using ‘ping’ is already slower. If using ‘ping’, scans can be slowed down or
- sped up, if desired, by using the threads option, such as by specifying
- “threads=2”. Using the threads option has less impact on nmap threads, which
- use a single thread to scan an entire network.
-
-Minor new features
-------------------
-
-**First User Journey - Import your SSH keys from Launchpad or Github**
- The ability to import SSH keys from Launchpad or Github was introduced in
- MAAS alpha 3. As of alpha 4, you can do so via the Front-end.
-
- All users will now have the ability to import their SSH keys from the UI.
- All users who log-in to MAAS for the first time will be prompted to import
- their SSH keys, if they so desire. Alternatively, users can do so via their
- user profile page.
-
-Other notable changes
----------------------
-
-**NTP Improvements - MAAS NTP vs External**
- MAAS now provides the ability to decide between using solely an external NTP
- server or a MAAS run NTP server. MAAS run NTP services is the preferred
- configuration, but, in order to maintain backwards compatibility,
- administrators can chose to use external NTP organizations. This will only
- be suitable for scenarios where administrators have restricted communication
- between their machines and the MAAS rack controllers.
-
-Bugs fixed in this release
---------------------------
-
-#1625668    [2.1] When trying to add SSH keys for a GH user that doesn't exist, there's no feedback
-#1626748    [2.1] maas admin discoveries scan API output shows rack controller ids instead of names
-#1626722    [2.1] DHPv6 addresses do not have netmasks: do not create /128 subnets for them
-#1625812    [2.1] Error message is not user friendly
-#1625689    [2.1] default gateway cannot be set to fe80::/64 via web ui
-#1626727    [2.1] You can define distribution or component for 'ubuntu archive' or 'ubuntu extra architectures'
-#1625671    [2.1] Need better error message when trying to add SSH keys for LP/GH user that doesn't exist
-#1623994    [2.1] DHCP configuration breaks when NTP servers are unresolvable.
-#1626669    [2.1] Can't logout, create users and do other actions
-#1625674    [2.1] No feedback when there are no keys to import from LP/GH
-
-Known issues and workarounds
-----------------------------
-
-**LP: #1623634: Unable to cancel the image import.**
- When downloading images, MAAS will fail to cancel the import of all or
- any of the images being imported. MAAS will first download all the images
- before the user is able to remove them.
-
- See bug `1617596`_ for more information.
-
-.. _1617596:
-  http://launchpad.net/bugs/1617596
-
-**LP: 1624693: Rack failed to run/register on fresh install**
- The MAAS Rack Controller is unable to register after a fresh install due to
- being unable to parse network interfaces. After manual restart of maas-rackd,
- the rack was successfully registered.
-
- See bug `1624693`_ for more information.
-
-.. _1624693:
-  http://launchpad.net/bugs/1624693
-
-
-2.1.0 (alpha 3)
-===============
-
-Major new features
-------------------
-
-**First User Configuration Journey (UI)**
- Starting from alpha 3, MAAS now provides the ability for administrators to
- perform some initial configuration when they log-in into the UI for the
- first time. The configuration includes:
-
-  * Ability to change the name of your MAAS.
-  * Ability to configure options that affect connectivity:
-  * Option to select an Upstream DNS Server (Optional)
-  * Option to input different Ubuntu Mirrors (Required).
-  * Option to input an external proxy (Optional)
-  * Ability to select additional images to download.
-
-**MAAS time sync, NTP services and configuration**
- Starting from alpha 3, MAAS now provides managed NTP services (with ntpd) in
- both the Region and Rack controller. This allows MAAS to not only keep its
- own controllers time synced, but the deployed machines as well.
-
- * Region Controller time syncs from external source
-   The Region Controller configures the NTP service (ntpd) to keep its time
-   sync from one or various external sources. By default, the MAAS region
-   controller syncs its time from ntp.ubuntu.com. The default can be changed
-   by one or multiple external NTP servers from the Settings page, under the
-   Network Configuration section.
-
- * Rack Controller time syncs from the Region Controller
-   The Rack Controllers also configure the NTP service (ntpd). Unlike the
-   Region Controllers, the Rack Controllers sync their time from the Region
-   Controller(s) instead of accessing directly to the external time source.
-
-   Additionally, the Rack Controllers also configure DHCP with the correct
-   NTP information, so that any machine on the network that DHCP’s from MAAS
-   can benefit of the NTP configuration.
-
- * Machines configured to sync time from external NTP (transitional).
-   MAAS also configures deployed machines with NTP configuration. This is done
-   by cloud-init via MAAS vendor data.
-
-   During the transition period, MAAS will configure machines to use the
-   external time source (configured under the Settings page). Note that this
-   is transitional, as in future releases the machines will default to the
-   Rack Controller for NTP.
-
-**MAAS Images page re-written in AngularJS**
- Continuing the transition from YUI to AngularJS, the MAAS Images page has now
- been completely redesigned and reimplemented in AngularJS. Improvements to
- the Image page include:
-
- * Ability to select the image source (maas.io or custom repository).
-   Show the releases and architectures available in the custom repository
-   before the import starts.
-
- * Ability to view the status of the image in the import process.
-   Show percentage based progress on the image import.
-
- Additionally, the ‘Boot Images’ section in the Settings page has been removed.
-
-**Minor new features**
-
- * (Backend) Ability to import SSH keys from Launchpad and Github
-   MAAS now provides the ability to import SSH keys for a user from Launchpad
-   and Github. This is currently supported via the API or via the user
-   creation process. Users can import their SSH keys when creating their user
-   for Launchpad or Github:
-
-    maas createadmin --ssh-import lp:<user-id>
-    maas createadmin --ssh-import gh:<user-id>
-
-   Or via the API based CLI with:
-
-    maas <maas username> sshkeys import protocol=lp auth_id=<user-id>
-    maas <maas username> sshkeys import protocol=gh auth_id=<user-id>
-
- * MAAS now provides cloud-init vendor data for NTP
-   As of MAAS 2.1 alpha 3, MAAS now provide cloud-init vendor data. Vendor
-   data allows cloud-init to do some initial configurations on the system
-   before user data is being run. As of 2.1, MAAS will provide NTP
-   configuration which is delivered via vendor data. Note that this is
-   dependent on the latest version of cloud-init (0.7.8-1-g3705bb5-0ubuntu1).
-   This is currently available in Yakkety and is in progress to be available
-   in Xenial.
-
- * Add ability to enable or disable network discovery
-   MAAS now provides the ability to disable the discovery of networks and
-   devices. By default, discovery is enabled. This setting can be changed
-   under the Settings page, or via the MAAS CLI and API using the
-   “network_discovery” configuration key. (Accepted values are “enabled” and
-   “disabled”.) When discovery is disabled, mDNS records and ARP requests will
-   no longer be stored in MAAS, and the listening processes on each rack
-   controller will be shut down.
-
-Other notable changes
----------------------
-
-**HTML template updates**
- In MAAS 2.1 alpha 3, the HTML templates and SCSS framework has been
- completely rebuilt and using the current Vanilla CSS framework as its base.
- This includes all design patterns and utility classes which would be expected
- of a powerful frontend GUI framework.
-
- HTML and CSS templates have been completely redesigned to use the new
- “Vanilla” styles. This brings a refreshed look of icons and interactions that
- benefit the UI. While users may not see much difference, it has been
- completely re-implemented in the backend.
-
- Thank you the design and web teams for their contribution to MAAS.
-
-Known issues and workarounds
-----------------------------
-
-**Unable to cancel the image import.**
- When downloading images, MAAS will fail to cancel the import of all or any of
- the images being imported. MAAS will first download all the images before the
- user is able to remove them.
-
- See bug `1623634`_ for more information.
-
-.. _1623634:
-  http://launchpad.net/bugs/1623634
-
-**Unable to enable DHCP if NTP server is unresolvable.**
- If the NTP server(s) are unresolvable, DHCP will fail to enable. This is
- because DHCP doesn’t accept DNS names for DHCP’s NTP configuration, and as
- such, MAAS tries to resolve the domain before it is able to set it in the
- configuration.
-
- See bug `1623994`_ for more information.
-
-.. _1623994:
-  http://launchpad.net/bugs/1623994
-
-**Rack failed to run/register on fresh install**
- The MAAS Rack Controller is unable to register after a fresh install due to
- being unable to parse network interfaces. After manual restart of maas-rackd,
- the rack was successfully registered.
-
- See bug `1624693`_ for more information.
-
-.. _1624693:
-  http://launchpad.net/bugs/1624693
-
-
-2.1.0 (alpha2)
-==============
-
-Important Announcements
------------------------
-
-**commissioning-user-data and pxe/uefi templates no longer available**
- In the past, MAAS stored commissioning-user-data and pxe/uefi templates
- in `/etc/maas/templates`. As of MAAS 2.1.0 Alpha 2, these templates are
- no longer available under /etc/maas.
-
-Major New Features
-------------------
-
-**(Backend) Device Discovery**
- As of MAAS 2.1.0 Alpha 2, MAAS will automatically listen to the network
- and report any observed devices.
-
-  * New discovery API can be used to get information about what MAAS has
-    discovered. This API can be used from the command line interface as
-    follows:
-
-    * maas <profile> discoveries read - Lists all MAC, IP bindings
-      (discoveries) that MAAS has seen, and attempts to correlate those
-      discoveries with hostnames advertised by mDNS.
-    * maas <profile> discoveries by-unknown-mac - Lists all discoveries,
-      but filters out discoveries where the MAC belongs to an interface
-      known to MAAS.
-    * maas <profile> discoveries by-unknown-ip - Lists all discoveries,
-      but filters out discoveries where the IP address is known to MAAS
-      (such as reserved by a user, or assigned to a node).
-    * maas <profile> discoveries by-unknown-ip-and-mac - Lists all discoveries,
-      but applies the filters for both unknown MACs and unknown IP addresses.
-
-  * Note that the discovery API is currently read-only. It brings together
-    data from several different sources, including observed network neighbours,
-    resolved mDNS hostnames, and controller interface information.
-  * New maas-rack commands have been added, which are called internally by
-    MAAS in order to gather information about observed devices on the network.
-    MAAS administrators should not normally need to use these commands
-    (although they could be helpful for supportability).
-
-    * maas-rack observe-mdns [--verbose]
-    * sudo maas-rack observe-arp <interface> [--verbose]
-
-  * Note: this feature intentionally does not place any network devices into
-    “promiscuous mode”, or actively probe. MAAS controllers listen to ARP
-    traffic they would have received anyway. Therefore, if a MAAS admin wants
-    to keep MAAS’s knowledge of the network up-to-date, a command such as one
-    of the following could be run periodically (such as from a script invoked
-    by a crontab); MAAS will listen to any ARP replies and update its knowledge
-    of the network:
-
-     * To actively probe one or more subnet CIDRs on an interface:
-       sudo nmap -e <interface> -sn -n -oX - -PR <cidr> [cidr2] [...]
-
-     * To actively probe for a single IP address from a particular interface
-       (regardless of whether or not the IP address is routable on-link on that
-       interface):
-       ping -r -I <interface> <ip-address> -c 3 -w 1 -i 0.2 -D -O
-
-  * MAAS now depends on the avahi-utils and tcpdump packages in order to provide
-    this functionality. (Before MAAS 2.1.0 is released, the MAAS team will consider
-    making these optional dependencies, in case MAAS administrators do not want
-    to run the avahi daemon, or require that tcpdump not be installed.)
-
-Important Bugs Fixed in this Release
-------------------------------------
-
-**Bug #1617596: [2.1] Rack(relay) Controller is rejected after upgrade to 2.1**
- Fixes a regression regarding registering rack controllers which have bonds
- interfaces which are not currently bonding any interfaces.
-
- See bug `1617596`_ for more information.
-
-.. _1617596:
-  http://launchpad.net/bugs/1617596
-
-**Bug #1615618: [2.1] 'SERVICE_STATE' object has no attribute 'getStatusInfo'**
- Fixes a regression in the service tracking mechanism, where it would fail to
- successfully track the status of some services.
-
- See bug `1615618`_ for more information.
-
-.. _1615618:
-  http://launchpad.net/bugs/1615618
-
-
-Other Notable Changes
----------------------
-
-**WebUI - Better error surfacing for DHCP snippets and Package Repositories**
- Both the DHCP Snippets Section and the Package Repositories section have now
- been improvement and will surface better errors.
-
-Ongoing Work
-------------
-
- * First User Journery - WebUI
- * Device Discovery - WebUI
- * Improved IPv6 Support
- * MAAS Services - NTP
- * MAAS Image Consolidation
- * Support for HWE Rolling Kernels
-
-Known Issues and Workarounds
-----------------------------
-
-**Configuring APT key’s in ephemeral environment (overlayfs) fails.**
- A regression preventing cloud-init from configuring APT's key in a
- ephemeral environment, prevents MAAS from enlisting, commissioning and
- deploying `only` when using Derived Repositories or Custom Mirrors that
- require a new key.
-
- See bug `1618572`_ for more information.
-
-.. _1618572:
-  http://launchpad.net/bugs/1618572
+**Migrating MAAS L3 to L2 spaces**
+ MAAS 2.2 has changed the definition of spaces from a Layer 3 concept to a
+ Layer 2 concept.
+
+ The spaces definition in MAAS (first introduced in MAAS 1.9) is “a set of
+ subnets that can mutually communicate”. The assumption is that these spaces
+ can route to each other, and have appropriate firewall rules for their
+ purposes. (For example, a dmz space might contain subnets with internet
+ access, and a storage space might contain subnets that can access the same
+ storage networks.) Juju uses the current definition in order to ensure that
+ deployed applications have access to networks appropriate for the services
+ they provide.
+
+ The current definition of spaces as a L3 concept is problematic, in that
+ sometimes Juju wants to deploy applications that themselves create a Layer 3
+ subnet. Therefore, it was decided that the concept of spaces will be pushed
+ down a layer (to apply to VLANs in MAAS).
+
+ With spaces as a Layer 2 concept, it is is now “a set of VLANs whose subnets
+ can mutually communicate”.
+
+ As such, starting from MAAS 2.2b1:
+
+  * VLANs will gain a ‘space’ reference, and subnets will have their spaces
+    migrated to the VLANs they are on. On upgrades, if two subnets on the same
+    VLAN are in different spaces, the most recently created space will be used
+    for both.
+
+  * Spaces will become optional. Fresh installs will not have a default space
+    (e.g. space-0). On upgrades, if only the default space (space-0) exists,
+    it will be removed.
+
+ The following API changes will occur in MAAS 2.2:
+
+  * Editing a subnet's space will no longer be possible (breaks backwards
+    compatibility). Spaces must now be edited each VLAN. For backward
+    compatibility, the subnets endpoint will present the underlying VLAN’s space.
+
+ Recommended actions for MAAS administrators prior to upgrading to MAAS 2.2:
+
+  * Ensure that no two subnets in the same VLAN are in different spaces, so that
+    the upgrade path migrates the expected space to the VLAN. Ensure that each
+    VLAN with an assigned space will contain subnets which can mutually
+    communicate with other subnets whose VLAN is in the same space. This will
+    allow backward compatibility with Juju charms which use the Layer 3 definition
+    of spaces.
+
+ NOTE: Please note that not breakage is expected, provided that most people are not
+ using spaces. For those who we know are, they are using them in a compatible way.
+ If you experience some type of issue, please contact us.
+
+Major new features
+------------------
+
+**DHCP Relay support**
+ The ability to model the usage of DHCP relays in your networking configuration has
+ been added to MAAS. The allows an administrator to identify which VLANs will be
+ relayed through another VLAN running a MAAS DHCP server. This will configure the
+ MAAS DHCP server running on the primary and/or secondary rack controller to include
+ the shared network statement for that VLAN. Note: MAAS does not run a DHCP relay
+ service, it is up to the administrator to configure the DHCP relay service on the
+ VLAN and point it at the primary and/or secondary rack controller running the MAAS DHCP.
+
+**Unmanaged subnets**
+ In MAAS 2.0, the concept of a “static range” (a specific range of addresses in which
+ MAAS was allowed to freely allocate addresses from) was removed from MAAS, in favor
+ of the idea that MAAS managing entire subnets. As such, the only way to tell MAAS to
+ not allocate certain sections of a subnet is to add a reserved IP range.
+
+ Starting from MAAS 2.2b1, however, MAAS enhances this functionality by introducing a
+ new concept, called unamanged subnets. Setting a Subnet in MAAS as unmanaged, allows
+ administrators to prevent MAAS from using that subnet for automatic IP assignment.
+ In other words, it is a way to tell MAAS that it knows about a subnet but that it
+ shouldn’t use it.
+
+Other notable changes
+---------------------
+
+**MAAS is now responsive**
+ For all of those users that use (or would like to use) MAAS WebUI from their Phone
+ or Tablet, will now have a better user experience, provided that starting from
+ 2.2b1, MAAS is now responsive.
+
+ Phone or Table users will see a new slick design for those devices. Thanks for
+ the Ubuntu Web team for putting the effort into making MAAS look great in smaller
+ devices.
+
+Known issues and workarounds
+----------------------------
+
+**Cannot add a device from the dashboard**
+ Please see LP #1659959 for more information.
+
+ https://bugs.launchpad.net/maas/+bug/1659959

=== modified file 'docs/conf.py'
--- docs/conf.py	2016-03-28 13:54:47 +0000
+++ docs/conf.py	2017-02-28 15:11:34 +0000
@@ -24,7 +24,8 @@
 from pytz import UTC
 
 # Configure MAAS's settings.
-environ.setdefault("DJANGO_SETTINGS_MODULE", "maas.settings")
+environ.setdefault(
+    "DJANGO_SETTINGS_MODULE", "maasserver.djangosettings.settings")
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the

=== removed file 'docs/configure.rst'
--- docs/configure.rst	2016-03-28 13:54:47 +0000
+++ docs/configure.rst	1970-01-01 00:00:00 +0000
@@ -1,135 +0,0 @@
-Additional Configuration
-========================
-
-
-Choosing a series to install
-----------------------------
-
-You may have some specific reason to choose a particular version of Ubuntu
-to install on your nodes, perhaps based around package availability,
-hardware support or some other reason.
-
-It is possible to choose a specific series from those available in a
-number of ways.
-
-From the user interface
-^^^^^^^^^^^^^^^^^^^^^^^
-
-The web-based user interface makes it easy to select which Ubuntu series you
-wish to install on an individual node. When either adding a node
-manually, or on the node page when the node has been automatically
-discovered but before it is accepted, there is a drop down menu to select
-the version of Ubuntu you wish to install.
-
-.. image:: media/series.*
-
-The menu will always list all the currently available series according
-to which boot images are available.
-
-Using the maas command
-^^^^^^^^^^^^^^^^^^^^^^
-
-It is also possible to select a series using the maas command. This
-can be done on a per node basis with::
-
- $ maas <profile> machine update <system_id> distro_series="<value>"
-
-Where the string contains one of the valid, available distro series (e.g.
-"trusty") or is empty for the default value.
-
-
-.. _preseed:
-
-Altering the Preseed file
--------------------------
-
-.. warning::
-  Do not try to alter the preseed files if you don't have a good
-  understanding of what you are doing. Altering the installed version
-  of Ubuntu can prevent MAAS from working as intended, and may have
-  security and stability consequences.
-
-When MAAS commissions a node it installs a version of Ubuntu. The
-installation is performed using a 'preseed' file, which is
-effectively a list of answers to the questions you would get were
-you to run the installer manually.
-The preseed file used by MAAS is carefully made so that the
-target node can be brought up and do all the jobs expected of it.
-However, in exceptional circumstances, you may wish to alter the
-pressed file to work around some issue.
-There are actually two preseed files, stored here::
-
-  /etc/maas/preseeds/curtin_userdata
-
-The preseed file is used to customize the installation of a machine
-based on different options. Users can set early_commands or late_commands
-according to what they need, or customize it based on nodes, architecture
-and other variables. The preseeds offers a concept that will allow users
-to configure it as required. This is based on a node's ::
-
-    node.system_id
-    node.hostname
-    node.domain
-    node.owner
-    node.bios_boot_method
-    node.osystem
-    node.distro_series
-    node.architecture
-    node.min_hwe_kernel
-    node.hwe_kernel
-    node.zone
-    node.cpu_count
-    node.memory
-
-You can configure the preseed to add late_commands. For example,
-you can configure the preseed to install a package based on the hostname,
-and after the installation has been completed::
-
-    late_commands:
-    {{if node.hostname == 'node01'}}
-        package_install: ["curtin", "in-target", "--", "apt-get", "-y", "install", "mysql"]
-    {{endif}}
-
-
-Installing Additional Rack Controllers
---------------------------------------
-
-In an environment comprising large numbers of nodes, it is likely that you will
-want to organise the nodes on a more distributed basis. The standard install of
-the MAAS region controller includes a rack controller, but it is
-possible to add additional rack controllers to the configuration, as
-shown in the diagram below:
-
-.. image:: media/orientation_architecture-diagram.*
-
-Each rack controller will need to run on a separate Ubuntu server.
-Installing and configuring the software is straightforward though::
-
-  $ sudo apt-get install maas-rack-controller
-
-This meta-package will install all the basic requirements of the system.
-
-
-Configuring the Rack Controller
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Follow the instructions at :doc:`rack-configuration` to configure
-additional Rack Controllers.
-
-
-Client-side DNS configuration
------------------------------
-
-When using a third party tool such as ``juju`` it will need to be able to
-resolve the hostnames that the MAAS API returns to it.  In order for this to
-happen, *client-side DNS* must be configured to point to MAAS's DNS
-server.  Generally speaking, this is a simple case of adding the following
-line to the ``/etc/resolv.conf`` file on your client host::
-
-  nameserver <IP OF MAAS DNS HOST>
-
-replacing the <IP OF MAAS DNS HOST> with the actual IP address of the host
-running the MAAS DNS server.
-
-However, for hosts using the ``resolvconf`` package, please read its
-documentation for more information.

=== added file 'docs/development/notifications.rst'
--- docs/development/notifications.rst	1970-01-01 00:00:00 +0000
+++ docs/development/notifications.rst	2017-02-28 15:11:34 +0000
@@ -0,0 +1,198 @@
+Notifications
+=============
+
+When you need to inform or warn users, administrators, or a specific
+user about something that has happened or is happening, consider using
+notifications. These can be created by code running in the region or via
+the Web API if you're an administrator.
+
+Tell all users that MAAS is on fire:
+
+  >>> from maasserver.models.notification import Notification
+
+  >>> Notification.objects.create_error_for_users("MAAS is on fire.")
+  <Notification ERROR user=None users=True admins=True 'MAAS is ...>
+
+Warn all admins that MAAS is taking on water:
+
+  >>> Notification.objects.create_warning_for_admins(
+  ...     "MAAS is taking on water.")
+  <Notification WARNING user=None users=False admins=True ...>
+
+Tell a specific user that they've won the lottery:
+
+  >>> from maasserver.testing.factory import factory
+  >>> user = factory.make_User()
+
+  >>> Notification.objects.create_success_for_user(
+  ...     "Congratulations {name}! You've won €10 in the lottery!",
+  ...     user=user, context={"name": user.username})
+  <Notification SUCCESS user='...' users=False admins=False ...>
+
+
+Context
+-------
+
+A notification's ``context`` is a dict — saved into the database as JSON
+— that gets interpolated into the message (new-style, not %-based).
+What's its purpose?
+
+  >>> Notification.objects.create_warning_for_admins(
+  ...     "Disk space is low; only {amount:0.2f} GiB remaining.",
+  ...     context={"amount": 1.3}, ident="disk-space-warning")
+  <Notification WARNING user=None users=False admins=True 'Disk space ...'>
+
+Later:
+
+  >>> ds_warning = Notification.objects.get(ident="disk-space-warning")
+  >>> ds_warning.context = {"amount": 0.8}
+  >>> ds_warning.save()
+
+This will update the message, live, in the browser, but will not show it
+again to people that have dismissed it already.
+
+This could be done by just changing the message! True, but the context
+does give a convenient location for context of all kinds; it does not
+have to be consumed by the message:
+
+  >>> ii_warning = Notification.objects.create_warning_for_users(
+  ...     "Image import from {url} has failed.",
+  ...     ident="import:http://foobar.example.com/",
+  ...     context={
+  ...         "url": "http://foobar.example.com/",
+  ...         "failures": ["2016-02-14 13:58:37"],
+  ...     })
+
+Later, after another failure:
+
+  >>> ii_warning = Notification.objects.get(
+  ...     ident="import:http://foobar.example.com/")
+  >>> ii_warning.context["failures"].append("2016-02-14 16:58:02")
+  >>> ii_warning.context["count"] = len(ii_warning.context["failures"])
+  >>> ii_warning.context["hours"] = 3  # Calculate this.
+  >>> ii_warning.message = (
+  ...     "Image import from {url} has failed {count} times "
+  ...     "in the last {hours} hours.")
+  >>> ii_warning.save()
+  >>> ii_warning.render()
+  'Image import from http://foobar.example.com/ has
+   failed 2 times in the last 3 hours.'
+
+
+Rendering and HTML
+------------------
+
+As you can see, rendering the message and context should be done with
+the ``render`` method:
+
+  >>> ds_warning.render()
+  'Disk space is low; only 0.80 GiB remaining.'
+
+Why?
+
+Notifications are primarily for a browser environment and so some
+limited amount of HTML is tolerated — it's sanitised by AngularJS in the
+UI so nothing fancy will get through.
+
+The ``render`` method knows about this and allows HTML content in the
+*message* through, but escapes the *context*:
+
+  >>> ds_warning.message = "Hello <em>{name}</em>!"
+  >>> ds_warning.context = {"name": "<script>nasty();</script>"}
+  >>> ds_warning.render()
+  'Hello <em>&lt;script&gt;nasty();&lt;/script&gt;</em>!'
+
+
+Creating notifications
+----------------------
+
+There are many methods to create notifications
+
+
+For a specific user:
+^^^^^^^^^^^^^^^^^^^^
+
+  >>> Notification.objects.create_error_for_user("abc", user)
+  <Notification ERROR user='...' users=False admins=False 'abc'>
+  >>> Notification.objects.create_warning_for_user("abc", user)
+  <Notification WARNING user='...' users=False admins=False 'abc'>
+  >>> Notification.objects.create_success_for_user("abc", user)
+  <Notification SUCCESS user='...' users=False admins=False 'abc'>
+  >>> Notification.objects.create_info_for_user("abc", user)
+  <Notification INFO user='...' users=False admins=False 'abc'>
+
+
+For all users:
+^^^^^^^^^^^^^^
+
+  >>> Notification.objects.create_error_for_users("abc")
+  <Notification ERROR user=None users=True admins=True 'abc'>
+  >>> Notification.objects.create_warning_for_users("abc")
+  <Notification WARNING user=None users=True admins=True 'abc'>
+  >>> Notification.objects.create_success_for_users("abc")
+  <Notification SUCCESS user=None users=True admins=True 'abc'>
+  >>> Notification.objects.create_info_for_users("abc")
+  <Notification INFO user=None users=True admins=True 'abc'>
+
+These methods create notifications that are visible to both users and
+admins:
+
+  >>> notification = Notification.objects.create_info_for_users("abc")
+  >>> notification.users
+  True
+  >>> notification.admins
+  True
+
+
+For administrators:
+^^^^^^^^^^^^^^^^^^^
+
+  >>> Notification.objects.create_error_for_admins("abc")
+  <Notification ERROR user=None users=False admins=True 'abc'>
+  >>> Notification.objects.create_warning_for_admins("abc")
+  <Notification WARNING user=None users=False admins=True 'abc'>
+  >>> Notification.objects.create_success_for_admins("abc")
+  <Notification SUCCESS user=None users=False admins=True 'abc'>
+  >>> Notification.objects.create_info_for_admins("abc")
+  <Notification INFO user=None users=False admins=True 'abc'>
+
+
+For users and **not** administrators:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Using the test factory, or by creating a ``Notification`` directly, it's
+possible to create a notification that's only for users and not for
+admins:
+
+  >>> notification = factory.make_Notification(users=True, admins=False)
+  >>> admin = factory.make_admin()
+  >>> notification.is_relevant_to(admin)
+  False
+
+This isn't explicitly catered for in the model API. If you find a need
+for this use case, adapt ``NotificationManager`` to accommodate it.
+
+
+Finding notifications
+---------------------
+
+Finding notifications that are both:
+
+- relevant to a particular user, and
+
+- have not been dismissed by that user
+
+should be done with ``find_for_user``:
+
+  >>> Notification.objects.find_for_user(user)
+  [<Notification ...]
+
+
+Well-formed messages
+--------------------
+
+If you use HTML, don't forget to close tags and otherwise respect all
+the proper rules of HTML.
+
+Finally, punctuation. Don't forget to end notification messages with a
+full-stop or exclamation mark!

=== removed file 'docs/devices.rst'
--- docs/devices.rst	2015-05-20 14:56:13 +0000
+++ docs/devices.rst	1970-01-01 00:00:00 +0000
@@ -1,28 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _devices:
-
-Devices
-========
-
-.. note::
-
-  This feature is available in MAAS versions 1.8 and above.
-  If you're writing a client application, you can check if MAAS
-  supports this feature via the web API; see the documentation for the
-  ``devices-management`` capability :ref:`here<cap-devices-management>`.
-
-In addition to nodes, a MAAS cluster controller can manage *devices*. Devices
-represent non-installable machines. This feature can be used to track
-routers, virtual machines, etc. within MAAS.
-
-Same as nodes, devices can be assigned IP addresses and DNS names. IP
-addresses can be fixed, in which case the device should be configured to use
-the defined IP address, or dynamic, in which case the device can obtain an
-IP address from the MAAS DHCP server and will receive the configured IP
-address.
-
-Devices can also be assigned a parent node and will be automatically deleted
-(along with all the IP address reservations associated with it) when the
-parent node is deleted or released. This is designed to model and manage the
-virtual machines or containers running on a MAAS-deployed node.
\ No newline at end of file

=== removed file 'docs/dhcpsnippets.rst'
--- docs/dhcpsnippets.rst	2016-03-28 16:52:32 +0000
+++ docs/dhcpsnippets.rst	1970-01-01 00:00:00 +0000
@@ -1,111 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _dhcpsnippets:
-
-=========================
-DHCP Snippets
-=========================
-
-.. note::
-
-  This feature is available in MAAS versions 2.0 and above. Modifications made
-  directly to dhcpd.conf.template or dhcpd6.conf.template are no longer
-  supported.
-
-MAAS allows customizing dhcpd.conf and dhcpd6.conf through the use of DHCP
-snippets. DHCP snippets are user defined dhcpd.conf configuration options which
-are inserted into /var/lib/maas/dhcpd.conf and /var/lib/maas/dhcpd6.conf by
-MAAS. Custom dhcpd.conf configuration options can be inserted either globally,
-on a subnet, or on a node. For information about dhcpd.conf options refer to
-the dhcpd.conf man or info page.
-
-Creating a DHCP Snippet
------------------------
-
-Administrators can create DHCP Snippets over the API using the following command:::
-
-  $ maas <profile> dhcpsnippets create name=<DHCP Snippet Name> value=<valid DHCP configuration options>
-
-The name of the DHCP snippet will be added to /var/lib/maas/dhcpd.conf and
-/var/lib/maas/dhcpd6.conf as a comment above the value. Optionally a
-description can also be specified as such::
-
-  $ maas <profile> dhcpsnippets create name=<DHCP Snippet Name> value=<valid DHCP configuration options> description=<DHCP Snippet description>
-
-Global DHCP Snippets
-^^^^^^^^^^^^^^^^^^^^
-
-If no subnet or node is specified, the DHCP Snippet will be considered global.
-A global DHCP Snippet is a configuration option which is applied to all VLANS,
-subnets, and nodes. The global_snippet flag can also be used to force a DHCP
-Snippet to be global::
-
-  $ maas <profile> dhcpsnippets create name=<DHCP Snippet Name> value=<valid DHCP configuration options> global_snippet=true
-
-Subnet DHCP Snippets
-^^^^^^^^^^^^^^^^^^^^
-
-DHCP Snippets can be applied only to a specific subnet as follows::
-
-  $ maas <profile> dhcpsnippets create name=<DHCP Snippet Name> value=<valid DHCP configuration options> subnet=<subnet id or cidr>
-
-Node DHCP Snippets
-^^^^^^^^^^^^^^^^^^
-
-DHCP Snippets can be applied only to a specific node. When a node is specified,
-each snippet will be added to the host entry for each interface. A node can be
-specified as follows::
-
-  $ maas <profile> dhcpsnippets create name=<DHCP Snippet Name> value=<valid DHCP configuration options> node=<system_id or hostname>
-
-DHCP Snippet Enablement
-^^^^^^^^^^^^^^^^^^^^^^^
-
-DHCP Snippets can be turned off by using the enabled flag option as follows::
-
-  $ maas <profile> dhcpsnippets create name=<DHCP Snippet Name> value=<valid DHCP configuration options> enabled=false
-
-Listing DHCP Snippets
----------------------
-
-To list all DHCP Snippets use the following command::
-
-  $ maas <profile> dhcpsnippets read
-
-To list a particular DHCP Snippet use the following command.::
-
-  $ maas <profile> dhcpsnippet read <DHCP Snippet id or name>
-
-Updating a DHCP Snippet
------------------------
-
-Administrators can update the DHCP Snippet attributes using the following
-command::
-
-  $ maas <profile> dhcpsnippet update <DHCP Snippet id or name> <options>
-
-DHCP Snippet Value History
---------------------------
-
-MAAS stores the complete history of changes made to the DHCP Snippet's
-value. MAAS only uses the latest revision of the value when writing
-dhcpd.conf.
-
-Reverting a Value
-^^^^^^^^^^^^^^^^^
-
-.. warning::
-  Reverting a value will result in all later versions being deleted!
-
-The revert operation allows the user to revert to a previous value. When
-specifying what to revert to the user can either provide the value id or a
-negative number representing how many revivisions to go back::
-
-  $ maas <profile> dhcpsnippet revert <DHCP Snippet id or name> to=<value id or negative number>
-
-Deleting a DHCP Snippet
------------------------
-
-Administrators can delete a DHCP Snippet using the following command::
-
-  $ maas <profile> dhcpsnippet delete <DHCP Snippet id or name>

=== removed file 'docs/getting-help.rst'
--- docs/getting-help.rst	2014-08-20 12:07:13 +0000
+++ docs/getting-help.rst	1970-01-01 00:00:00 +0000
@@ -1,49 +0,0 @@
-************
-Getting help
-************
-
-Where to get help
------------------
-
-The two channels you can use to get help debugging a MAAS issue are:
-
-- The `Ask Ubuntu`_ website.
-- The `Freenode #maas`_ IRC channel.
-
-.. _Ask Ubuntu:
-  http://askubuntu.com/questions/ask?tags=maas
-
-.. _Freenode #maas:
-  http://webchat.freenode.net/?channels=maas
-
-
-Gathering debugging information
--------------------------------
-
-If your question is related to a problem related to a specific MAAS installation, we encourage you to gather debugging information and make it available before you head over to Ask Ubuntu or the IRC channel.  This way, you'll have all the required information handy for people who can help you.
-
-Gathering debugging information is a fully automated process that is performed with the help of `sosreport`_.
-
-If your MAAS server is running Ubuntu version 14.04 (Trusty Tahr) or later, you can get sosreport from the official archives::
-
-  # Install sosreport.
-  sudo apt-get install -y sosreport
-  # Create the report.
-  sudo sosreport -o maas
-
-Alternatively, if your MAAS server is running a previous Ubuntu release, you'll need to install sosreport manually::
-
-  # Install git.
-  sudo apt-get install -y git
-  # Get the latest version of sosreport.
-  git clone https://github.com/sosreport/sosreport.git /tmp/sosreport
-  # Create the report.
-  sudo /tmp/sosreport/sosreport -o maas
-
-.. _sosreport:
-  https://github.com/sosreport/sosreport
-
-This will create a tarball containing MAAS' log files, MAAS' configuration files and a dump of MAAS' database.  By default, the tarball will end up in /tmp but you can change the location, see sosreport's manpage for details.  If there are things you do not wish to share publicly, feel free to edit the tarball.
-
-Now, the last step is to make this file available by any means at your disposal (openly accessible FTP server, Dropbox, etc.) in order for the people who will help you to be able to get their hands on it.
-

=== removed file 'docs/ha.rst'
--- docs/ha.rst	2016-06-03 23:10:17 +0000
+++ docs/ha.rst	1970-01-01 00:00:00 +0000
@@ -1,290 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _ha:
-
-High Availability (HA) Configuration
-====================================
-
-MAAS 2.0+ supports high availability (HA) across its entire architecture. HA
-can be enabled at the rack controller level allowing the ability for
-controlling BMCs, providing DHCP, and deploying machines to span across
-multiple rack controllers. At the region controller level, HA can be provided
-for the API, WebUI, DNS, and APT proxy.
-
-
-Rack Controller HA
-------------------
-
-Rack controller HA is provided for BMCs out of the box. MAAS will
-automatically identify which rack controllers can communicate to which BMCs
-and pass BMC actions to the correct rack controllers.
-
-To provide HA for deploying machines, DHCP HA must be turned on. DHCP HA in
-MAAS allows a primary and a secondary DHCP server to run on the same VLAN. This
-allows a deploying machine to request an IP address from either DHCP server
-(primary first) for PXE booting. The responding rack controller will then
-handle PXE booting the machine and loading the required files to complete the
-deployment. All lease information will be replicated between the primary and
-secondary rack controller, allowing one rack controller to fail without
-interrupting MAAS operation.
-
-Enabling DHCP HA
-^^^^^^^^^^^^^^^^
-
-DHCP works at the VLAN level, providing interfaces connected to that VLAN the
-ability to get an IP address on a subnet. This requires a subnet be defined
-on the VLAN where DHCP will be enabled, along with a range of IPs that will be
-assigned to unknown interfaces (called the 'dynamic range'). Enabling DHCP HA
-is the same as enabling DHCP without HA; setting a secondary rack controller
-will turn DHCP HA on. Follow the instructions at :doc:`rack-configuration` to
-enable DHCP HA.
-
-
-Region Controller HA
---------------------
-
-Region controller HA is more complicated, in that MAAS allows you to configure
-this in many different configurations. Any number of region controllers can
-be added to MAAS, as long as they connect to the same PostgreSQL database. The
-only state that is held in MAAS is in the database, allowing region controllers
-to be scaled up and scaled down at will.
-
-Initial Region Controller
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The first step to enabling HA for the MAAS region controller is installing the
-``maas-region-controller`` package. This package configures everything for you
-to start using the MAAS region controller on one machine. It initializes a new
-database, runs the migrations, and sets up the default configuration files for
-the new MAAS region controller to run. ::
-
-    $ sudo apt update
-    $ sudo apt install maas-region-controller
-
-.. note::
-
-  This installs and configures the PostgreSQL database on the same machine as
-  the region controller. When possible, this is the recommended configuration.
-  MAAS requires database access to be fast, since all MAAS state (including
-  operating system images, which will be synchronized with each rack
-  controller).
-
-Enabling PostgreSQL HA
-^^^^^^^^^^^^^^^^^^^^^^
-
-MAAS stores all state information in the PostgreSQL database, so it is key to
-place this into an HA configuration. PostgreSQL supports many different HA
-configurations, but hot standby is recommended as it allows the secondary
-database to become the primary quickly and the MAAS region controller can
-quickly switch to using the secondary database server as the primary. For
-configuring hot standby, the following wiki provides a quick start guide on
-setting it up: `https://wiki.postgresql.org/wiki/Hot_Standby`_.
-
-.. _https://wiki.postgresql.org/wiki/Hot_Standby:
-  https://wiki.postgresql.org/wiki/Hot_Standby
-
-Extra Region Controller
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Since this new region will not be setting up its own database, use the
-following packages to set up the new region controller::
-
-    maas-region-api maas-dns
-
-In order to add another region controller to MAAS, you will also need the
-*regiond.conf* from the initial region controller. This will allow the new
-region controller to connect to the same PostgreSQL database. You will want to
-adjust the database_host in the *regiond.conf* to point to the primary database
-for PostgreSQL.::
-
-    $ sudo apt update
-    $ sudo apt install maas-region-api maas-dns
-    $ sudo systemctl stop maas-regiond
-    $ sudo rm /var/lib/maas/{maas_id,secret}
-    $ sudo scp <ubuntu@initial-region>:/etc/maas/regiond.conf /etc/maas/regiond.conf
-    $ sudo chown root:maas /etc/maas/regiond.conf
-    $ sudo chmod 640 /etc/maas/regiond.conf
-    $ sudo maas-region local_config_set --database-host <postgresql-primary-ip>
-    $ sudo systemctl restart maas-regiond
-
-Now if you check the MAAS UI or the API, you will see that MAAS has another
-region controller. But one issue still exists: the ``bind9`` service will
-refuse to start. This is because both BIND and MAAS define some of the same
-options in their respective configuration files. Since BIND will not allow you
-to use the same option more than once, MAAS needs to migrate the options from
-the BIND configuration. ::
-
-    $ sudo maas-region edit_named_options --migrate-conflicting-options
-    $ sudo systemctl restart bind9
-
-After that, you should have another fully functioning MAAS region controller!
-The DNS configuration and proxy configuration across all region controllers
-will stay synced, and you have another server to access the MAAS WebUI and API
-endpoints.
-
-Load Balancing Between Regions (optional)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-With multiple region controllers, there are several options for load balancing.
-One approach is to only use one region controller all the time, and fail over
-to another using a virtual IP (VIP). Another approach is to use a load-balancer
-and a VIP, to distribute the workload across all active region controllers.
-In this example, we will use ``haproxy`` to configure load balancing across the
-MAAS region controllers.
-
-First (on each region controller) ``apache2`` needs to be disabled. While the
-``maas-region-api`` package depends on ``apache2`` for its default
-configuration, it will conflict with ``haproxy`` (or any other load balancer
-running on port 80) if it is enabled. ::
-
-    $ sudo systemctl stop apache2
-    $ sudo systemctl disable apache2
-
-Now that ``apache2`` is disabled, ``haproxy`` can be installed and configured.
-You will want to change the <server-name> and <server-ip> in the proxy
-configuration below to match your infrastructure. ::
-
-    $ sudo apt install haproxy
-    $ sudo sh -c 'cat >>/etc/haproxy/haproxy.cfg <<EOL
-
-    frontend maas
-        bind    *:80
-        retries 3
-        option  redispatch
-        option  http-server-close
-        default_backend maas
-
-    backend maas
-        timeout server 30s
-        balance roundrobin
-        server localhost localhost:5240 check
-        server <server-name-1> <server-ip-1>:5240 check
-        server <server-name-2> <server-ip-2>:5240 check
-    EOL'
-    $ sudo systemctl restart haproxy
-
-.. note::
-
-  It is recommended to run a load-balancer on every region controller server
-  and place a VIP between the servers. This will ensure that the load is
-  balanced between the servers, and ensure that (if a failure occurs) the
-  VIP moves over to the another server (which could then distribute
-  requests to the remaining servers).
-
-VIP between the Regions
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Whether you configured a load-balancer or not, a VIP (virtual IP) is needed.
-The VIP will be used by the rack controllers (and the deploying machines) to
-access the region controller API endpoint. In this example, we will show how to
-use ``keepalived`` to configure a VIP.
-
-You will need to adjust checks below, depending on if you are using
-``apache2``, or ``haproxy``. You will also need to configure the
-interface_name, priority, random_password, and the VIP in the configuration
-below. The priority needs to be between 1-255. Larger priority numbers
-indicate a greater preference for the server to claim the VIP. ::
-
-    $ sudo apt install keepalived
-    $ sudo modprobe ip_vs
-    $ sudo sh -c 'echo modprobe ip_vs >> /etc/modules'
-    $ sudo sh -c 'echo net.ipv4.ip_nonlocal_bind=1' > /etc/sysctl.d/60-keepalived-nonlocal.conf
-    $ sudo systemctl restart procps
-    $ sudo sh -c 'cat >>/etc/keepalived/keepalived.conf <<EOL
-
-    # Un-comment when using haproxy.
-    #vrrp_script chk_haproxy {
-    #    script "killall -0 haproxy"
-    #    interval 2
-    #}
-
-    # Un-comment when using apache2.
-    #vrrp_script chk_apache2 {
-    #    script "killall -0 apache2"
-    #    interval 2
-    #}
-
-    vrrp_script chk_named {
-        script "killall -0 named"
-        interval 2
-    }
-
-    vrrp_instance maas_region {
-        state MASTER
-        interface <interface_name>
-        priority <priority>
-        virtual_router_id 51
-
-        authentication {
-            auth_type PASS
-            auth_pass <random_password>
-        }
-
-        track_script {
-            # Un-comment when using haproxy
-            #chk_haproxy
-            # Un-comment when using apache2
-            #chk_apache2
-            chk_named
-        }
-
-        virtual_ipaddress {
-            <vip>
-        }
-    }'
-    $ sudo systemctl restart keepalived
-
-.. note::
-
-  If you are enabling this inside of a container, the host of the container
-  needs the ip_vs module loaded and the sysctl change. A restart of the
-  container is required once the change has been made in the host.
-
-Once ``keepalived`` has been configured you will want to adjust the
-MAAS_URL on all region controllers and rack controllers to point to that VIP.
-That will ensure that all clients and machines use that IP address for
-communication.
-
-On the rack controller's::
-
-    $ sudo maas-rack config --region-url http://<vip>/MAAS
-    $ sudo systemctl restart maas-rackd
-
-On the region controller's::
-
-    $ sudo maas-region local_config_set --maas-url http://<vip>/MAAS
-    $ sudo systemctl restart maas-regiond
-
-
-Deploying HA with Juju
-----------------------
-
-Now that you have an understanding of how to configure HA manually, it
-is possible to use Juju to deploy MAAS in an HA configuration. Using Juju
-allows you to quickly scale up or scale down the MAAS infrastructure in a
-configuration supported by the MAAS team.
-
-.. note::
-
-  Using Juju to deploy MAAS is not normally how Juju would be used.
-  Normally, you would first install MAAS, then use Juju to deploy services on
-  MAAS-managed machines. However, we can use Juju's manual provisioning
-  support to deploy MAAS to existing Ubuntu systems.
-
-In the following example, Juju is bootstrapped with manual provisioning,
-the machines intended to be used for MAAS services are added, and the services
-are deployed and linked together. Be sure to adjust the given numbers based
-on what you see in the "juju status" command. (See the Juju documentation
-for more details.) The following commands could be used to deploy MAAS::
-
-    $ juju bootstrap maas manual/<ip-of-server>
-    $ juju add-machine ssh:<ip-of-server>
-    ... add required machines ...
-    $ juju deploy postgresql --to 0
-    $ juju add-unit postgresql --to 1
-    $ juju deploy maas-region --to 0
-    $ juju add-unit maas-region --to 1
-    $ juju add-relation maas-region:db postgresql:db
-    $ juju deploy maas-rack --to 3
-    $ juju add-unit maas-rack --to 4
-    $ juju add-relation maas-region:rpc maas-rack:rpc

=== removed file 'docs/hardware-enablement-kernels.rst'
--- docs/hardware-enablement-kernels.rst	2015-08-26 02:32:49 +0000
+++ docs/hardware-enablement-kernels.rst	1970-01-01 00:00:00 +0000
@@ -1,80 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _hardware-enablement-kernels:
-
-=================================
-Using hardware-enablement kernels
-=================================
-
-.. note::
-
-  As of MAAS 1.9 this feature is configured by setting the hwe_kernel variable
-  instead of the architecture variable.
-
-MAAS allows you to use hardware enablement kernels when booting nodes
-with Ubuntu that require them.
-
-What are hardware-enablement kernels?
--------------------------------------
-
-Brand new hardware gets released all the time. We want that hardware to
-work well with Ubuntu and MAAS, even if it was released after the latest
-release of MAAS or Ubuntu. Hardware Enablement (HWE) is all about keeping
-pace with the new hardware.
-
-Ubuntu's solution to this is to offer newer kernels for older releases.
-There are at least two kernels on offer for Ubuntu releases: the
-"generic" kernel -- i.e. the kernel released with the current series --
-and the Hardware Enablement kernel, which is the most recent kernel
-release.
-
-There are separate HWE kernels for each release of Ubuntu, referred to
-as ``hwe-<release letter>``. So, the 14.04 / Trusty Tahr HWE kernel is
-called ``hwe-t``, the 12.10 / Quantal Quetzal HWE kernel is called
-``hwe-q`` and so on. This allows you to use newer kernels with older
-releases, for example running Precise with a Saucy (hwe-s) kernel.
-
-For more information see the `LTS Enablement Stack`_ page on the Ubuntu
-wiki.
-
-.. _LTS Enablement Stack:
-   https://wiki.ubuntu.com/Kernel/LTSEnablementStack
-
-
-Booting hardware-enablement kernels
------------------------------------
-
-MAAS imports hardware-enablement kernels along with its generic boot
-images. These hardware-enablement kernels are specified by using min_hwe_kernel
-or hwe_kernel variables.
-
-The min_hwe_kernel variable is used to instruct MAAS to ensure the release to
-be deployed uses a kernel version at or above the value of min_hwe_kernel. For
-example if min_hwe_kernel is set to hwe-t when deploying any release before
-Trusty the hwe-t kernel will be used. For any release after Trusty the default
-kernel for that release will be used. If hwe-t or newer is not availible for
-the specified release MAAS will not allow that release to be deployed and throw
-an error.
-
-min_hwe_kernel can be set by running the command::
-
-  $ maas <profile-name> node update <system-id>
-    min_hwe_kernel=hwe-<release letter>
-
-It's also possible to set the min_hwe_kernel from the MAAS web UI, by visiting
-the Node's page and clicking ``Edit node``. Under the Minimum Kernel field, you
-will be able to select any HWE kernels that have been imported onto that node's
-cluster controller.
-
-.. image:: media/min_hwe_kernel.png
-
-You can also set the hwe_kernel during deployment. MAAS checks that the
-specified kernel is avalible for the release specified before deploying the
-node. You can set the hwe_kernel when deploying by using the command::
-
-  $ maas <profile-name> node start <system-id> distro_series=<distro>
-  hwe_kernel=hwe-<release letter>
-
-Or through the web interface as seen below.
-
-.. image:: media/hwe_kernel.png

=== modified file 'docs/index.rst'
--- docs/index.rst	2016-08-15 09:54:43 +0000
+++ docs/index.rst	2017-02-28 15:11:34 +0000
@@ -39,54 +39,10 @@
 .. toctree::
    :maxdepth: 2
 
-   about
-   orientation
    releases
    changelog
 
 
-************************
-Setting up a MAAS server
-************************
-
-.. toctree::
-   :maxdepth: 2
-
-   install
-   configure
-   rack-configuration
-   ha
-   static-ips
-   ipv6
-   bootsources
-   nodes
-   hardware-enablement-kernels
-   sstreams-mirror
-   networking
-   kernel-options
-   installing-ubuntu
-   os-support
-   storage
-   networking
-   proxy
-   devices
-   dhcpsnippets
-   packagerepositories
-   power-driver-capabilities
-
-
-******************
-Deploying services
-******************
-
-.. toctree::
-   :maxdepth: 2
-
-   juju-quick-start
-   tags
-   physical-zones
-
-
 ***********************
 API / CLI Documentation
 ***********************
@@ -100,17 +56,6 @@
    version
 
 
-***************
-Troubleshooting
-***************
-
-.. toctree::
-   :maxdepth: 2
-
-   getting-help
-   troubleshooting
-
-
 ******************
 Command-line Tools
 ******************
@@ -140,6 +85,7 @@
    development/tagging
    development/preseeds
    development/metadata
+   development/notifications
    development/rpc
    development/transactions
    development/notes/index

=== removed symlink 'docs/install.rst'
=== target was u'../INSTALL.txt'
=== removed file 'docs/installing-ubuntu.rst'
--- docs/installing-ubuntu.rst	2016-05-11 19:01:48 +0000
+++ docs/installing-ubuntu.rst	1970-01-01 00:00:00 +0000
@@ -1,36 +0,0 @@
-=====================================
-Installing Ubuntu and deploying nodes
-=====================================
-
-Once a node has been accepted into MAAS and is ready for use, users can
-deploy services to that node.
-
-Prior to deployment, MAAS is responsible for:
-
-1. Powering up the node.
-2. Installing Ubuntu on the node (with the help of :ref:`curtin
-   <curtin-installer>`).
-3. Installing the user's SSH keys on the node.
-
-Once these steps have been completed, the node is ready to have services
-deployed to it, either manually or by using a tool like Juju_.
-
-.. _Juju: http://juju.ubuntu.com
-
-
-.. _curtin-installer:
-
-Curtin: The Curt Installer
---------------------------
-
-As the name suggests this installs Ubuntu on a node more quickly than
-would be possible using the traditional Debian installer.
-
-Curtin is enabled by default and is the only mechanism for installing
-Ubuntu supported by MAAS. It copies a pre-built Ubuntu image to the
-node, with all the packages installed that would be normally found in an
-Ubuntu installation. It's very fast!
-
-For more information about curtin, see its `project page`_ on Launchpad.
-
-.. _project page: https://launchpad.net/curtin

=== removed file 'docs/ipv6.rst'
--- docs/ipv6.rst	2014-10-10 13:36:03 +0000
+++ docs/ipv6.rst	1970-01-01 00:00:00 +0000
@@ -1,150 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _ipv6:
-
-Managing IPv6 Networks
-======================
-
-.. note::
-
-  This feature is available in MAAS versions 1.7 and above, starting with
-  lp:maas revision 2992.  If you're writing a client application that makes use
-  of this feature, you can query the region-server API for the
-  ``ipv6-deployment-ubuntu`` :ref:`capability<cap-ipv6-deployment-ubuntu>`.
-
-MAAS has limited IPv6 support for networking nodes.  It works much like IPv4
-support, but with a number of limitations:
-
-* Nodes still boot, register, and install using the IPv4 network.
-* IPv6 addresses are only configured when using the default Ubuntu installer.
-* Most BMCs can only be controlled (e.g. to power nodes on/off) using IPv4.
-* MAAS still uses IPv4 for its internal operation, installing nodes, etc.
-* For now, MAAS only supports IPv6 on networks where it also manages IPv4 DHCP.
-* A network interface on a node can only be on one IPv6 subnet.
-* A network interface on a cluster controller can manage only one IPv6 subnet.
-
-The web user interface and REST API can be accessed in the same way on both
-IPv4 and IPv6.  To use an IPv6 address as the hostname in a URL, in your
-browser or elsewhere, surround it with square brackets.  For example, on the
-local machine (``::1``, the IPv6 equivalent of ``localhost``) you might
-request::
-
-    http://[::1]/MAAS/
-
-If your MAAS server has a DNS hostname that resolves to both IPv4 and IPv6
-addresses, your browser may already be accessing the UI through IPv6 without
-you noticing.
-
-
-Enabling IPv6
--------------
-
-You enable IPv6 networking in the same way that you enable IPv4 networking:
-configure a separate cluster interface for your IPv6 subnet, in addition to the
-one you need for your IPv4 subnet.  The IPv6 cluster interface must define a
-static address range.  Provided that you already have a functioning IPv6
-network, that's all there is to it.  The following sections will go into more
-detail about what is supported, what is needed, and what to do if you don't yet
-have a functioning IPv6 network.
-
-An IPv6 cluster interface can use the same network interface on the cluster
-controller as an existing IPv4 network interface.  It just defines a different
-subnet, with IPv6 addressing.  A node that's connected to the IPv4 subnet will
-also be connected to the IPv6 subnet on the same network segment.
-
-
-Configuring your IPv6 subnet
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When you configure your IPv6 cluster interface, be sure to define a static IP
-address range.  Deployed nodes on the subnet will get static addresses in this
-range.
-
-IPv6 networks are normally 64 bits wide, so you can be generous with the
-ranges' sizes.  It also means that you can leave the netmask field blank.
-
-(There are no broadcast addresses in IPv6, so leave the broadcast address field
-blank as well.)
-
-You may want MAAS to manage DHCP and DNS, but it's not required.  In fact nodes
-do not need a DHCP server at all for IPv6; MAAS configures static IPv6
-addresses on the node's network interfaces while deploying it.  A DHCPv6 server
-can provide addresses for containers or virtual machines running on the nodes,
-as well as devices on the network that are not managed by MAAS, but it is not
-needed for the nodes themselves.  MAAS will not be aware of any addresses
-issued by DHCP, and does not guarantee that they will stay unchanged.
-
-
-.. _ipv6-routing:
-
-Routing
-^^^^^^^
-
-In IPv6, clients do not discover routes through DHCP.  Routers make themselves
-known on their networks by sending out *route advertisements*.  These *RAs*
-contain other configuration as well: whether clients should statelessly
-configure their own unique IP addresses based on their MAC addresses; whether
-they should request stateless configuration from a DHCP server; and finally,
-whether they should request a stateful IP address from a DHCP server.  Since a
-network interface can have any number of IPv6 addresses even on a single
-subnet, several of these address assignment mechanisms can be combined.
-
-However, when MAAS configures IPv6 networking on a node, it does not rely on
-RAs.  it statically configures your nodes' default IPv6 route to use the router
-that is configured on the cluster interface, so that the nodes will know their
-default gateway.  They do not need DHCP and will not autoconfigure global
-addresses.
-
-However, if you are planning to operate DHCPv6 clients as well, e.g. on
-machines not managed by MAAS or on virtual machines hosted by MAAS nodes, you
-may still want to have RAs configured to make those clients obtain
-configuration over DHCP.
-
-If you need RAs but your gateway does not send them, install and configure
-``radvd`` somewhere on the network to advertise its route.
-
-
-Other installers and operating systems
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Static IPv6 addresses are currently only configured on Ubuntu, when installed
-using the "fast" installer.  Other operating systems, or Ubuntu with the
-classic Debian installer, will not have their IPv6 addresses configured.
-The same applies when a user manually installs an operating system on a node,
-or overwrites its networking configuration: the node will no longer have its
-static IPv6 address configured, even if MAAS has allocated it to the node.
-
-However, as long as the address remains allocated to the node, you may still
-configure its operating system to use that address.  The node can then use that
-address as if it had been configured by MAAS.
-
-
-Disabling IPv4
---------------
-
-For advanced users, there is an experimental capability to deploy nodes with
-pure IPv6, with IPv4 networking disabled.  To enable this on a node, check the
-"Disable IPv4 when deployed" box on the node's Edit page.  The process of
-managing and deploying the node will still largely work through IPv4, but once
-deployed, the node will have IPv6 networking only.
-
-In practice nodes may not be functional without IPv4 networking.  A few things
-are known to be needed in any case:
-
-
-Configuring the MAAS URL
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The *maas-cluster-controller* package has a configuration item for the URL
-where nodes and cluster controllers can reach the MAAS region API.
-
-By default, this URL is set based on the region controller's IPv4 address.  To
-make it work for nodes that won't have IP4, you must set the MAAS URL to use
-a hostname instead of an IP address.  The hostname must resolve to both IPv4
-and IPv6 addresses, and both on the cluster controller and on the nodes.
-
-To change this setting, run::
-
-    dpkg-reconfigure maas-cluster-controller
-
-It will prompt you for the URL, with its current setting as the initial value.

=== removed file 'docs/juju-quick-start.rst'
--- docs/juju-quick-start.rst	2016-01-25 14:10:29 +0000
+++ docs/juju-quick-start.rst	1970-01-01 00:00:00 +0000
@@ -1,145 +0,0 @@
-Juju Quick Start
-================
-
-These instructions will help you deploy your first charm with Juju to
-a MAAS cluster.
-
-In the following, we assume that you have a MAAS cluster set-up with at least
-2 nodes enlisted with it.
-
-
-Your API key, SSH key, and environments.yaml
---------------------------------------------
-
-You'll need an API key from MAAS so that the Juju client can access
-it. Each user account in MAAS can have as many API keys as desired.
-One hard and fast rule is that you'll need to use a different API key
-for each Juju *environment* you set up within a single MAAS cluster.
-
-There is no need to explicitly add an SSH key to MAAS when using Juju;
-it will automatically put your public key on any hosts that it starts up.
-
-**Note**: You do not need to use the MAAS web UI or API to allocate
-a node to yourself, Juju will do this for you.
-
-
-Getting a key
-^^^^^^^^^^^^^
-
-To get the API key:
-
-#. Go to your MAAS preferences page (go to your MAAS home page
-   ``http://${my-maas-server}:80/MAAS/`` and choose *Preferences* from the
-   drop-down menu that appears when clicking your username at the top-right
-   of the page).
-
-#. Optionally add a new MAAS key. Do this if you're setting up another
-   environment within the same MAAS cluster.
-
-The ``${my-maas-server}`` slot should be replaced with the hostname of your
-MAAS server.
-
-
-Adding an SSH key
-^^^^^^^^^^^^^^^^^
-
-While you're still on the MAAS preferences page, add your SSH key
-by clicking *Add SSH key*. Use the public half of your SSH key, the
-content of ``~/.ssh/id_rsa.pub`` for example; don't paste the private
-half.
-
-
-Creating environments.yaml
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Create or modify ``~/.juju/environments.yaml`` with the following content::
-
-  environments:
-    maas:
-      type: maas
-      maas-server: 'http://${my-maas-server}:80/MAAS'
-      maas-oauth: '${maas-api-key}'
-      admin-secret: ${your-admin-secret}
-      default-series: precise
-
-Substitute the API key from earlier into the ``${maas-api-key}``
-slot, and the hostname of your MAAS server into the ``${my-maas-server}``
-slot.
-
-The ``${your-admin-secret}`` slot should be replaced with a random pass-phrase,
-there is no default.
-
-
-Now Juju
---------
-
-If juju-core is not yet installed on the client machine, run::
-
-  $ sudo apt-get install juju-core
-
-Now, use juju to display the status of the default environment::
-
-  $ juju status
-
-As you've not bootstrapped you ought to see::
-
-  error: Unable to connect to environment "".
-  Please check your credentials or use 'juju bootstrap' to create a new environment.
-
-**Note**: if Juju complains that there are multiple environments and
-no explicit default, add ``-e ${environment-name}`` after each
-command, e.g.::
-
-  $ juju status -e maas
-
-Bootstrap::
-
-  $ juju sync-tools
-  $ juju bootstrap
-
-If bootstrapping on a version of juju older than 1.14.0 then use::
-
-  $ juju bootstrap --upload-tools
-
-This will return quickly, but the master node may take a *long* time
-to come up. It has to completely install Ubuntu and Juju on it and
-reboot before it'll be available for use. It's probably worth either
-trying a ``juju status`` once in a while to check on progress, or
-following the install on the node directly.
-
-  **Beware** of `bug 413415`_ - *console-setup hangs under chroot
-  debootstrap with a console login on ttyX* - when monitoring an
-  installation on the node.
-
-.. _bug 413415:
-  https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/413415
-
-Once the boostrap node has been installed a status command should
-come up with something a bit more interesting::
-
-  environment: maas
-  machines:
-    "0":
-      agent-state: started
-      agent-version: 1.13.3.1
-      dns-name: kmhwd.master
-      instance-id: /MAAS/api/2.0/nodes/node-5c5b713a-1afc-11e3-9904-525400123456/
-      series: precise
-  services: {}
-
-Now it's possible to deploy a charm::
-
-  $ juju deploy mysql
-  $ juju status
-
-If you have another node free you can finish off the canonical and by
-now familiar example::
-
-  $ juju deploy wordpress
-  $ juju add-relation wordpress mysql
-  $ juju expose wordpress
-  $ juju status
-
-Note that each charm runs on its own host, so each deployment will
-actually take as long as it took to bootstrap. Have a beer, drown your
-sorrows in liquor, or, my preference, have another cup of tea.

=== removed file 'docs/kernel-options.rst'
--- docs/kernel-options.rst	2014-02-11 05:21:58 +0000
+++ docs/kernel-options.rst	1970-01-01 00:00:00 +0000
@@ -1,38 +0,0 @@
-===========================
-Setting kernel boot options
-===========================
-
-MAAS is able to send specific kernel options to booting nodes on both
-a global basis and a per-node basis.
-
-Global kernel options
----------------------
-
-As an admin, click on the gear icon at the top right and scroll down to
-the Global Kernel Parameters section, as shown here:
-
-.. image:: media/global_kernel_opts.png
-
-Whatever you set here is sent as-is to all booting nodes.
-
-Per-node kernel options
------------------------
-
-Per-node kernel options are set using tags.  The easiest way of doing this
-is to use the ``maas`` command.  You will need to :ref:`be
-logged in to the API first <api-key>` and then you can add a tag which has its
-``kernel_opts`` value set, like this::
-
-  $ maas maas tags new name='nomodeset' \
-    comment='nomodeset kernel option' kernel_opts='nomodeset vga'
-
-Once the tag is defined, you can add it to a node or nodes::
-
-  $ maas maas tag update-nodes nomodeset add=<system_id_1> \
-    add=<system_id_2>
-
-.. note::
-
-  Any per-node kernel options set will completely override the global options.
-  If multiple tags attached to a node have the kernel_opts defined, the first
-  one ordered by name is used.

=== removed file 'docs/networking.rst'
--- docs/networking.rst	2016-07-08 14:38:44 +0000
+++ docs/networking.rst	1970-01-01 00:00:00 +0000
@@ -1,270 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _networking:
-
-=========================
-Networking
-=========================
-
-.. note::
-
-  This feature is available in MAAS versions 1.9 and above on Ubuntu
-  deployments. If you're writing a client application, you can check
-  if MAAS supports this feature via the web API; see the documentation
-  for the ``network-deployment-ubuntu`` capability
-  :ref:`here<cap-network-deployment-ubuntu>`.
-
-MAAS 1.9 adds support for the modeling of a wide variety of networking concepts
-and configurations.
-
-Networking Concepts
--------------------
-
-At a high level, MAAS supports the following networking concepts:
-
-Fabrics
-^^^^^^^
-
-A fabric is a set of interconnected VLANs that are capable of mutual
-communication. A fabric can be thought of as a logical grouping in which VLANs
-can be considered unique.
-
-For example, a distributed network may have a fabric in London containing
-VLAN 100, while a separate fabric in San Francisco may contain a VLAN 100,
-whose attached subnets are completely different and unrelated.
-
-A "Default Fabric" is created when MAAS is installed (or upgraded).
-
-Subnets
-^^^^^^^
-
-A subnet is a "layer 3" network defined by a particular network prefix, plus
-a network mask length (in bits). This notation is also referred to as a *CIDR*.
-
-MAAS supports IPv4 and IPv6 subnets.
-
-Examples::
-
-    10.0.0.0/8
-    172.16.0.0/12
-    192.168.0.0/16
-    2001:db8:4d41:4153::/64
-
-Subnets can be annotated with a descriptive name, their default gateway,
-and/or their DNS server(s).
-
-A subnet can be in a single space.
-
-Subnets are considered managed if a cluster interface specifies the cluster
-network range.
-
-**IP Ranges**
-
-MAAS assumes it can allocate all unreserved IPs in a subnet. For example,
-MAAS will assign IPs out of the unreserved pool to node interfaces configured
-"IP Address" type "Auto assign". You can reserve IPs for other purposes by
-adding one or more "reserved ranges" in your subnet configuration.
-
-There are two kinds of reserved ranges: "Reserved Range" and "Reserved Dynamic
-Range". Use a "Reserved Range" to block out a set of static IPs that you plan
-to use for other devices on your network (e.g. managed switches or routers).
-
-Use a "Reserved Dynamic Range" to block out a set of IP addresses that you
-plan to hand out using a DHCP server. If you enable DHCP on your subnet's
-VLAN, MAAS will provide a DHCP for IPs in this range, otherwise you are
-responsible for proving an external DHCP server for this range.
-
-Note that a "Reserved Dynamic Range" with active DHCP is *required* if you
-have nodes that require DHCP to network boot (e.g. PXE clients), or if you
-have configured any node interfaces as "IP Address" type "DHCP".
-
-
-VLANs
-^^^^^
-
-VLANs (Virtual LANs) are a common way to create logically separate networks
-using the same physical infrastructure.
-
-Managed switches can assign VLANs to each port in either a "tagged" or an
-"untagged" manner. A VLAN is said to be "untagged" on a particular port when
-it is the default VLAN for that port, and requires no special configuration
-in order to access.
-
-"Tagged" VLANs (traditionally used by network administrators in order to
-aggregate multiple networks over inter-switch "trunk" lines) can also be used
-with nodes in MAAS. That is, if a switch port is configured such that "tagged"
-VLAN frames can be sent and received by a MAAS node, that MAAS node can be
-configured to automatically bring up VLAN interfaces, so that the deployed node
-can make use of them.
-
-A "Default VLAN" is created for every Fabric, to which every new VLAN-aware
-object in the fabric will be associated to by default (unless otherwise
-specified).
-
-Spaces
-^^^^^^
-
-A Space is a logical grouping of subnets that should be able to communicate
-with each other. Subnets within each space need not belong to the same fabric.
-For example, you may have a "DMZ" space in both your London and San Francisco
-fabrics, and a "Storage" space to indicate subnets attached to your storage
-network.
-
-A "space-0" is created when MAAS is installed (or upgraded), which
-every subnet will belong to by default (unless otherwise specified).
-
-Interfaces
-^^^^^^^^^^
-
-**Physical**
-
-After a node is commissioned, MAAS discovers its physical interfaces. In
-addition, devices are created with physical interfaces.
-
-Prior to deployment, a MAAS administrator can specify additional interfaces
-to be configured on the node, including one or more of the below types.
-
-**Bond**
-
-A bond interface is capable of aggregating two or more physical interfaces
-into a single logical interface. Bonds can be used in conjunction with a
-managed switch (using Link Aggregation and Control Protocol, or LACP), or
-independently (software bonds).
-
-**VLAN**
-
-A VLAN interface can be used to connect to a tagged VLAN, if the switch port
-the node is connected to is authorized to access it.
-
-**Unknown**
-
-Unknown interfaces cannot be created by users.
-
-Sometimes, *unknown* interfaces are discovered by MAAS. (For example, when
-MAAS learns of a new DHCP lease that is not associated with any known node
-or device.)
-
-How to Configure Nodes for Networking
--------------------------------------
-
-Creating a Bond Interface
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Use the ``node-interfaces create-bond`` API to create a bond. For example::
-
-    $ maas admin node-interfaces create-bond node-d83ce230-4b50-11e5-a267-00163eb185eb name=bond0 vlan=0 parents=30 parents=31 mac_address=00:50:56:2b:60:53
-    Success.
-    Machine-readable output follows:
-    {
-        "name": "bond0",
-        "links": [],
-        "tags": [],
-        "vlan": {
-            "id": 0,
-            "resource_uri": "/MAAS/api/2.0/fabrics/0/vlans/0/",
-            "name": "Default VLAN",
-            "vid": 0,
-            "fabric": "fabric-0"
-        },
-        "enabled": true,
-        "id": 41,
-        "parents": [
-            "eth0",
-            "eth1"
-        ],
-        "mac_address": "00:50:56:2b:60:53",
-        "type": "bond",
-        "children": [],
-        "resource_uri": "/MAAS/api/2.0/nodes/node-d83ce230-4b50-11e5-a267-00163eb185eb/interfaces/41/"
-    }
-
-Note that in the example above, the bond contains two interfaces because
-the ``parents`` parameter was specified twice, such as
-``parents=30 parents=31``.
-
-Creating a VLAN Interface
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To create a VLAN interface, use the ``node-interfaces create-vlan`` API.
-
-Be aware that the ``vlan`` paremeter does not indicate a VLAN ID that
-corresponds to the VLAN tag. You must first create the VLAN, and then
-associate it with the interface. For example::
-
-    $ maas admin vlans create 0 name="Storage network" vid=100
-    Success.
-    Machine-readable output follows:
-    {
-        "id": 1,
-        "resource_uri": "/MAAS/api/2.0/fabrics/0/vlans/1/",
-        "name": "Storage network",
-        "vid": 100,
-        "fabric": "fabric-0"
-    }
-
-Note that the ``0`` in the command above indicates the ``fabric_id``. If you
-have not defined any additional fabrics, the ``fabric_id`` of the default
-fabric will be ``0``.
-
-Now that a VLAN is created, it may be associated with a new interface::
-
-    $ maas admin node-interfaces create-vlan node-d83ce230-4b50-11e5-a267-00163eb185eb vlan=1 parent=30
-    Success.
-    Machine-readable output follows:
-    {
-        "name": "eth0.100",
-        "links": [],
-        "tags": [],
-        "vlan": {
-            "id": 1,
-            "resource_uri": "/MAAS/api/2.0/fabrics/0/vlans/1/",
-            "name": "Storage network",
-            "vid": 100,
-            "fabric": "fabric-0"
-        },
-        "enabled": true,
-        "id": 44,
-        "parents": [
-            "eth0"
-        ],
-        "mac_address": "00:50:56:2b:60:53",
-        "type": "vlan",
-        "children": [],
-        "resource_uri": "/MAAS/api/2.0/nodes/node-d83ce230-4b50-11e5-a267-00163eb185eb/interfaces/44/"
-    }
-
-
-Deleting an Interface
-^^^^^^^^^^^^^^^^^^^^^
-
-To delete an interface, use the ``node-interface delete`` API. For example::
-
-    $ maas admin node-interface delete node-d83ce230-4b50-11e5-a267-00163eb185eb 41
-    Success.
-
-Machine Interface Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**Auto Assign**
-
-Interfaces configured as "Auto assign" will be deployed with a static
-(non-DHCP) network configuration. MAAS will choose an IP from the subnet
-that does not fall into a defined reserved range.
-
-**Static**
-
-When you configure an interfaces as "Static", you will provide an IP address
-for that interface to use when deployed.
-
-**DHCP**
-
-Interfaces configured as "DHCP" will be configured to use DHCP to request
-configuration information at boot. In order for the interface to successfully
-configure, you will need to insure that a "Dynamic Range" has been reserved
-on the associated subnet, and that either you have configured MAAS to provide
-DHCP services on the associated VLAN, or that you have provided an external
-DHCP server to do so.
-
-**(Unconfigured)**
-
-These interfaces will be left unconfigured.

=== removed file 'docs/nodes.rst'
--- docs/nodes.rst	2016-03-28 13:54:47 +0000
+++ docs/nodes.rst	1970-01-01 00:00:00 +0000
@@ -1,98 +0,0 @@
-Adding nodes to the system
-==========================
-
-Now that the MAAS controller is running, we need to make the nodes
-aware of MAAS and vice-versa. If you have set up DHCP correctly, and
-your nodes can boot via PXE_ then things really couldn't be much easier
-and you can use :ref:`the automatic discovery procedure <auto-enlist>`.
-You do not need to install Ubuntu on nodes that you wish to add to MAAS
-prior to enlistment.
-
-To learn more about setting up DHCP, read the :ref:`cluster configuration
-documentation <rack-configuration>`.
-
-.. _PXE: http://en.wikipedia.org/wiki/Preboot_Execution_Environment
-
-.. _auto-enlist:
-
-Automatic Discovery
--------------------
-
-With nodes set to boot from a PXE image, they will start, look for a
-DHCP server, receive the PXE boot details, boot the image, contact the
-MAAS server and shut down.
-
-During this process, the MAAS server will be passed information about
-the node, including the architecture, MAC address and other details
-which will be stored in the database of nodes. You can accept and
-commission the nodes via the web interface.  When the nodes have been
-accepted the selected series of Ubuntu will be installed.
-
-To save time, you can also accept and commission all nodes from the
-commandline. This requires that you first log in with the API key,
-which :ref:`you can retrieve from the web interface <api-key>`::
-
-   $ maas maas nodes accept-all
-
-
-.. _enlist-via-boot-media:
-
-
-Manually add nodes
-------------------
-
-If you know the MAC address of a node, you can manually enter details
-about the node through the web interface. Click the ``Add Node`` button
-to be taken to the "Add Node" form:
-
-.. image:: media/add-node.png
-
-
-Virtual machine nodes
----------------------
-
-If you're setting up virtual machines to use as nodes with MAAS, you need
-to configure the power type as ``virsh``.  For MAAS to be able to use
-virsh, make sure you have the ``libvirt-bin`` package installed.
-
-.. note::
-
-  If you are assembling a set of VMs for testing or development, make
-  sure they have at least 512 MB (768 MB If you are deploying 15.10)
-  to avoid failures during deployment.
-
-The virsh power type takes two parameters:
-
-Power ID
-    The Power ID is the name of the virtual machine shown by
-    ``sudo virsh list --all``
-
-Address
-    This is a libvirt connection string, such as
-    ``qemu+ssh://ubuntu@10.0.0.2/system`` or ``qemu:///system``
-
-.. image:: media/virsh-config.png
-
-If you want to use ssh you'll need to generate a ssh key pair for the maas
-user.  By default there is no home directory created for the maas user::
-
-    $ sudo mkdir /home/maas
-    $ sudo chown maas:maas /home/maas
-
-Add a login shell for the maas user::
-
-    $ sudo chsh -s /bin/bash maas
-
-Become the maas user and generate a SSH keypair::
-
-    $ sudo su - maas
-    $ ssh-keygen -f ~/.ssh/id_rsa -N ''
-
-Then add the public key to ``/ubuntu/.ssh/authorized_keys`` on the vm server
-so virsh can use ssh without a password::
-
-    $ ssh-copy-id -i ~/.ssh/id_rsa ubuntu@10.0.0.2
-
-As the maas user, test virsh commands against libvirt at 10.0.0.2::
-
-    $ virsh -c qemu+ssh://ubuntu@10.0.0.2/system list --all

=== removed file 'docs/orientation.rst'
--- docs/orientation.rst	2014-08-22 00:13:24 +0000
+++ docs/orientation.rst	1970-01-01 00:00:00 +0000
@@ -1,107 +0,0 @@
-.. _orientation:
-
-Orientation
-===========
-
-
-MAAS in Brief
--------------
-
-Canonical’s MAAS brings the dynamism of cloud computing to the world
-of physical provisioning and Ubuntu. Connect, commission and deploy
-physical servers in record time, re-allocate nodes between services
-dynamically, and keep them up to date and in due course, retire them
-from use.
-
-MAAS is a new way of thinking about physical infrastructure. Compute,
-storage and network are commodities in the virtual world, and for
-large-scale deployments the same is true of the metal. “Metal as a
-service” lets you treat farms of servers as a malleable resource for
-allocation to specific problems, and re-allocation on a dynamic basis.
-
-In conjunction with the Juju service orchestration software (see
-https://juju.ubuntu.com/docs/), MAAS will enable you to get the most
-out of your physical hardware and dynamically deploy complex services
-with ease and confidence.
-
-
-Do I Need MAAS?
----------------
-
-MAAS certainly isn't for everyone, but why not ask yourself these
-questions?
-
-You probably *SHOULD* use MAAS if any or all of the following
-statements are true:
-
-    * You are trying to manage many physical servers.
-    * You want to deploy services with the minimum fuss.
-    * You need to get the most from your resources.
-    * You want things to work, repeatably and reliably.
-
-You probably don't need MAAS if any or all of these statements are
-true:
-
-    * You don't need to manage physical hardware
-    * You relish time spent in the server room
-    * You like trying to set up complicated, critical services without any help
-
-
-.. _setup:
-
-A Typical MAAS setup
---------------------
-
-MAAS is designed to work with your physical hardware, whether your
-setup includes thousands of server boxes or only a few. The key
-components of the MAAS software are:
-
-  * Region controller
-  * Cluster controller(s)
-  * Nodes
-
-The nodes are the computers you manage using MAAS.  These can range from just
-a handful to many thousands of systems.
-
-For small (in terms of number of nodes) setups, you will probably just
-install the Region controller and a cluster controller on the same
-server - it is only worth having multiple region controllers if you
-need to organise your nodes into different subnets (e.g. if you have a
-lot of nodes).  If you install the ``maas`` package, it will include both a
-region controller and a cluster controller, and they will be automatically
-set up to work together.
-
-.. image:: media/orientation_architecture-diagram.*
-
-
-How MAAS is used
-----------------
-
-MAAS manages a pool of nodes.  After registering a new system with the MAAS
-and preparing it for service ("commissioning"), the new system joins this pool.
-
-From the moment a node is accepted into the MAAS, any operating system,
-software, or data that it may have had installed before is meant to be
-overwritten.  A node in the pool is under MAAS's sole control, and off-limits
-to users.
-
-Once you have nodes in the pool, users of the MAAS can allocate them for their
-own use.  At that point, the nodes are installed with the selected operating
-system and set up with the user's login credentials for remote access.  This
-is referred to as "starting" a node in the browser interface, and as
-"acquiring" (and, as a separate step, "starting") a node in the API.
-
-When allocating from the API, you can specify constraints such as how much
-memory you need, how many CPUs, what networks the node should be connected to,
-what physical zone they should be in, and so on.  API commands can also be
-issued through the ``maas`` command-line utility.
-
-An allocated node is not like a virtual instance in a cloud: you get complete
-control, including hardware drivers and root access.  To upgrade a BIOS, for
-example, an administrator could allocate a node to themselves, and run a
-vendor-supplied upgrade utility.  Needless to say, you also get full hardware
-performance and tweaking!
-
-Once you are done with a node you have allocated, you can release it back to
-the pool.  Once again any data, software, or operating system will no longer
-be available.

=== removed file 'docs/os-support.rst'
--- docs/os-support.rst	2015-09-08 18:41:57 +0000
+++ docs/os-support.rst	1970-01-01 00:00:00 +0000
@@ -1,121 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _os-support:
-
-=========================
-Operating Systems Support
-=========================
-
-.. note::
-
-  This feature is available in MAAS versions 1.7 and above.
-
-Besides Ubuntu, MAAS allows users to deploy different operating
-systems, such as CentOS. Ubuntu Advantage customers can
-additionally deploy Redhat Enterprise Linux (RHEL), OpenSUSE, SLES,
-Window Server and Windows HyperV.
-
-
-Generated Images vs. Custom Images
-----------------------------------
-
-MAAS supports two different classes of OS images, `Generated images`
-and `Custom images`.
-
-`Generated images` are images of the OS' that MAAS team fully
-supports. Currently supported OS' are CentOS and Windows.
-
-`Custom images` are images that MAAS can deploy, but may have been
-customized and differ from those that the MAAS team supports. Custom
-images can include any Ubuntu, CentOS or Windows image. Additionally,
-Redhat Enterprise Linux (RHEL), OpenSUSE and SLES images also fall
-under this category.
-
-
-Installing MAAS Images
-----------------------
-
-Installing Generated Images
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing MAAS Generated Images (CentOS or Windows) can be done with
-the command::
-
-    $ maas admin boot-resources create name=<os/series>
-      architecture=<architecture> [filetype=ddtgz]
-      content@=<image-name>
-
-The list of supported Operating Systems under `Generated Images` is:
-
- * CentOS 6.5 (centos/centos65)
- * CentOS 7 (centos/centos7)
- * Windows Server 2012 (windows/win2012)
- * Windows Server 2012 R2 (windows/win2012r2)
- * Windows Hyper-V (windows/win2012hv)
- * Windows Hyper-V R2 (windows/win2012hvr2)
-
-Examples::
-
-    $ maas admin boot-resources create name=centos/centos7
-      architecture=amd64/generic content@=centos7-amd64-root-tgz
-
-    $ maas admin boot-resources create name=windows/win2012
-      architecture=amd64/generic filetype=ddtgz
-      content@=win2012-amd64-ddtgz
-
-Installing Custom Images
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing custom images require the user to specify a unique
-identifier for the OS and Release, as well as the title of the
-Image::
-
-    $ maas admin boot-resources create name=custom/<os-release-id>
-      title=<title> architecture=amd64/generic content@=<image-name>
-
-Examples::
-
-    $ maas admin boot-resources create name=custom/rhel7
-      title="RedHat Enterprise Linux 7" architecture=amd64/generic
-      content@=rhel7-amd64-root-tgz
-
-The list of tested Operating Systems under `Custom Images` is:
-
- * OpenSUSE
- * SLES 11 and SLES 12
- * Redhat Enterprise Linux 7 (RHEL7)
-
-
-MAAS Image Builder
-------------------
-
-The MAAS Image Builder is a script that allows users to generate their
-own images. However, ``maas-image-builder`` only supports the generation
-of CentOS and RHEL images. To install ``maas-image-builder``, please
-follow the instructions::
-
-  $ sudo apt-add-repository ppa:maas-maintainers/stable
-  $ sudo apt-get install maas-image-builder
-
-
-Creating and Installing CentOS MAAS Images
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note::
-
-  Supported CentOS versions are CentOS 6.5 (centos65) and CentOS 7 (centos7).
-
-
-To create a MAAS CentOS image, no ISO is needed as all of the required
-software to create the image is downloaded (from CentOS repositories) as part
-of the image generation process. To create the MAAS CentOS image,
-``maas-image-builder`` can be used as::
-
-    $ maas-image-builder -a amd64 -o centos7-amd64-root-tgz centos --edition 7
-
-The created image, ``centos7-amd64-root-tgz``, needs to be uploaded into the
-MAAS Region Controller. This image will be listed under the `Generated` Image
-Section in the `MAAS Image` page. This image can be uploaded with::
-
-    $ maas admin boot-resources create name=centos/centos7
-      architecture=amd64/generic content@=./build-output/centos7-amd64-root-tgz

=== removed file 'docs/packagerepositories.rst'
--- docs/packagerepositories.rst	2016-08-15 09:54:43 +0000
+++ docs/packagerepositories.rst	1970-01-01 00:00:00 +0000
@@ -1,71 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _packagerepositories:
-
-====================
-Package Repositories
-====================
-
-.. note::
-
-  This feature is available in MAAS versions 2.0 and above.
-
-MAAS allows the configuring of multiple additional package repositories, which
-will find their way into the /etc/apt/sources.list on MAAS deployed machines.
-
-Creating a Package Repository
------------------------------
-
-Administrators can create Package Repositories over the API using the following command:::
-
-  $ maas <profile> package-repositories create name=<Package Repository Name> url=<URL locating the package repository>
-
-These are the minimally required parameters - see the online API help,
-described below, for the complete list of parameters.
-
-Package Repository Enablement
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Package Repositories can be turned off by using the enabled flag option as follows:::
-
-  $ maas <profile> package-repositories create name=<Package Repository Name> url=<URL locating the package repository> enabled=false
-
-The enabled flag can be modified on an existing repository by using the update
-API, described below.
-
-Listing Package Repositories
-----------------------------
-
-To list all Package Repositories use the following command:::
-
-  $ maas <profile> package-repositories read
-
-To list a particular Package Repository use the following command:::
-
-  $ maas <profile> package-repository read <Package Repository id or name>
-
-Updating a Package Repository
------------------------------
-
-Administrators can update the Package Repository attributes using the following
-command:::
-
-  $ maas <profile> package-repository update <Package Repository id or name> <options>
-
-Deleting a Package Repository
------------------------------
-
-Administrators can delete a Package Repository using the following command:::
-
-  $ maas <profile> package-repository delete <Package Repository id or name>
-
-Getting Help
-------------
-
-Online help is available for all API's in MAAS. For example:::
-
-  $ maas <profile> package-repository --help
-  $ maas <profile> package-repository <command> --help
-
-  $ maas <profile> package-repositories --help
-  $ maas <profile> package-repositories <command> --help

=== removed file 'docs/physical-zones.rst'
--- docs/physical-zones.rst	2014-08-22 00:13:24 +0000
+++ docs/physical-zones.rst	1970-01-01 00:00:00 +0000
@@ -1,132 +0,0 @@
-Physical Zones
-==============
-
-.. note::
-  This feature is only available in MAAS versions 1.5 and above.
-
-To help you maximise fault-tolerance and performance of the services you
-deploy, MAAS administrators can define *physical zones* (or just *zones*
-for short), and assign nodes to them.  When a user requests a node, they can
-ask for one that is in a specific zone, or one that is not in a specific zone.
-
-It's up to you as an administrator to decide what a physical zone should
-represent: it could be a server rack, a room, a data centre, machines attached
-to the same UPS, or a portion of your network.  Zones are most useful when they
-represent portions of your infrastructure.  But you could also use them simply
-to keep track of where your systems are located.
-
-Each node is in one and only one physical zone.  Each MAAS instance ships with
-a default zone to which nodes are attached by default.  If you do not
-need this feature, you can simply pretend it does not exist.
-
-
-Applications
-------------
-
-Since you run your own MAAS, its physical zones give you more flexibility
-than those of a third-party hosted cloud service.  That means that you get to
-design your zones and define what they mean.  Below are some examples of how
-physical zones can help you get the most out of your MAAS.
-
-
-Using Zones for Fault Tolerance
-...............................
-
-If you are concerned about availability of services you deploy through MAAS, a
-physical zone could be on one power supply, or it could be an entire data
-centre location, or an area of your network that is unlikely to suffer problems
-when another zone experiences an outage.
-
-For example, you might roll out separate instances of the same web application
-into different physical zones of the same MAAS, and either load-balance
-between them or keep one as a warm stand-by.  If one zone suffers a power loss,
-is cut off from the internet, or is affected by a natural disaster, the other
-instance of your application may still be available in the other zone, and
-ready to take over.
-
-For fault tolerance, machines that work together in order to provide one
-instance of a service should generally be allocated in the same zone.  The
-entire service should have a backup instance in another zone.
-
-
-Using Zones for Performance
-...........................
-
-Even if fault tolerance is not an issue, you may still want to divide your
-nodes into groups that communicate efficiently through a high-performance local
-network, or share efficient access to external resources.
-
-When it comes to performance, machines should generally be allocated in the
-zone closest to performance-critical resources they need.
-
-For example, for applications that are highly sensitive to network latency, it
-may make sense to divide your MAAS into smaller physical networks, and
-represent each of those networks as a physical zone.  Now, you can use the
-physical zones to allocate nodes just where they get the best performance
-when communicating with specific other nodes.
-
-In another example, your application may rely on a third-party service
-available on the internet.  If your MAAS is spread out across multiple data
-centre locations, you may want the application to be deployed in the location
-with the best access to that service.
-
-
-Using Zones for Power Management
-................................
-
-If you are concerned about power density and cooling, you can lay out your
-physical zones to match server racks.  Instead of allocating machines that
-share a physical zone, you can spread out the load by ensuring that "hot"
-systems are in located different zones.
-
-
-Creating a Zone
----------------
-
-Only administrators can create and manage zones.  To create a physical
-zone in the web user interface, log in as an administrator and browse to the
-"Zones" section in the top bar.  This will takes you to the zones listing page.
-At the bottom of the page is a button for creating a new zone:
-
-.. image:: media/add-zone.*
-
-Or to do it in the :ref:`region-controller API <region-controller-api>`, POST
-your zone definition to the *"zones"* endpoint.
-
-
-Assigning Nodes to a Zone
--------------------------
-
-Once you have created one or more physical zones, you can set nodes' zones
-from the nodes listing page in the UI.  Select the nodes for which you wish to
-set a zone, and choose "Set physical zone" from the "Bulk action" dropdown
-list near the top.  A second dropdown list will appear, to let you select which
-zone you wish to set.  Leave it blank to clear nodes' physical zones.
-Clicking "Go" will apply the change to the selected nodes.
-
-You can also set an individual node's zone on its "Edit node" page.  Both ways
-are available in the API as well: edit an individual node through a ``PUT``
-request to the node's URI, or set the zone on multiple nodes at once by calling
-the ``set_zone`` operation on the ``nodes`` endpoint.
-
-
-Allocating a Node in a Zone
----------------------------
-
-To deploy in a particular zone, call the ``acquire`` method in the
-:ref:`region-controller API <region-controller-api>` as before, but pass the
-``zone`` parameter with the name of the zone.  The method will allocate a node
-in that zone, or fail with an HTTP 409 ("conflict") error if the zone has no
-nodes available that match your request.
-
-Alternatively, you may want to request a node that is *not* in a particular
-zone, or one that is not in any of several zones.  To do that, specify the
-``not_in_zone`` parameter to ``acquire``.  This parameter takes a list of zone
-names; the allocated node will not be in any of them.  Again, if that leaves no
-nodes available that match your request, the call will return a "conflict"
-error.
-
-It is possible, though not usually useful, to combine the ``zone`` and
-``not_in_zone`` parameters.   If your choice for ``zone`` is also present in
-``not_in_zone``, no node will ever match your request.  Or if it's not, then
-the ``not_in_zone`` values will not affect the result of the call at all.

=== removed file 'docs/power-driver-capabilities.rst'
--- docs/power-driver-capabilities.rst	2016-05-27 22:46:58 +0000
+++ docs/power-driver-capabilities.rst	1970-01-01 00:00:00 +0000
@@ -1,48 +0,0 @@
-.. -*- mode: rst -*-
-
-*************************
-Power Driver Capabilities
-*************************
-
-
-**2016-05-23, newell**
-
-MAAS has internal support for power controlling differents types of hardware.
-Not all the power drivers in MAAS have the same capabilities and the table below
-details the main differences amongst the power drivers.
-
-
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Power Driver                          | Set PXE On  | Power     |    Chassis    | Enhanced UI     |    BMC     |
-|                    X=Yes, Blank=No    |  Next Boot  | Querying  | Configuration | Error Reporting | Enlistment |
-+=========================+=============+=============+===========+===============+=================+============+
-| American Power Conversion (APC) - PDU |             |           |               |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Cisco UCS Manager                     |      X      |     X     |       X       |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Digital Loggers, Inc. - PDU           |             |           |               |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| HP Moonshot - iLO Chassis Manager     |      X      |     X     |       X       |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| HP Moonshot - iLO4 (IPMI)             |      X      |     X     |               |                 |     X      |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| IBM Hardware Management Console (HMC) |      X      |     X     |               |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| IPMI                                  |      X      |     X     |               |       X         |     X      |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Intel AMT                             |      X      |     X     |               |       X         |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Manual                                |             |           |               |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Microsoft OCS - Chassis Manager       |      X      |     X     |       X       |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| OpenStack Nova                        |             |     X     |               |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| SeaMicro 15000                        |      X      |     X     |       X       |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Sentry Switch CDU - PDU               |             |           |               |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| VMWare                                |      X      |     X     |       X       |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+
-| Virsh (virtual systems)               |      X      |     X     |       X       |                 |            |
-+---------------------------------------+-------------+-----------+---------------+-----------------+------------+

=== removed file 'docs/proxy.rst'
--- docs/proxy.rst	2016-04-07 17:04:26 +0000
+++ docs/proxy.rst	1970-01-01 00:00:00 +0000
@@ -1,81 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _proxy:
-
-Proxy Configuration
-===================
-
-In most cases, the machines deployed in a MAAS installation will use a proxy to
-access the archive.  Alternatively, MAAS can be told to use an externall
-configured proxy, or none at all.
-
-As of MAAS 2.0, the default MAAS region controller configuration will create a
-maas-proxy configuration that explicitly allows all of the subnets in the
-configuration to use it for a proxy.
-
-
-Assumptions
------------
-
-It is generally assumed that the MAAS region controller is not exposed to
-untusted networks.  (That is, that there is a firewall between the MAAS region
-controller and any such networks.)  Prior to MAAS 2.0, the only option if this
-was not the case was to manually edit /etc/maas/maas-proxy.conf, or use
-iptables to create a firewall on the host.
-
-As of MAAS 2.0, permission to use the proxy can be managed on a per-subnet
-basis. (The default is to allow proxying.)
-
-.. warning:: If your MAAS Region is connected to an untrusted network, you should disable that subnet in the proxy, as shown below.
-
-MAAS Proxy Installation
------------------------
-
-When you install a Region Controller, maas-proxy will be installed.  The
-configuration of the proxy relies on maas-proxy being on the same machine as
-the Region Controller.
-
-
-Using an external proxy
------------------------
-If you want to use an external proxy, see the Network Configuration section of
-the web user interface to set the proxy url.
-
-.. image:: media/external-proxy.png
-
-Alternatively, the following
-command will specify squid.example.com as the proxy, using port 3128::
-
- $ maas admin maas set-config name=http_proxy value=http://squid.example.com:3128/
-
-Disable proxying for a Subnet
------------------------------
-As an example, we will configure MAAS to disable the proxy for a subnet::
-
- $ maas admin subnet update 192.168.0.0/22 allow_proxy=False
-
-Enable proxying for a Subnet
-----------------------------
-To re-enable the proxy for that subnet::
-
- $ maas admin subnet update 192.168.0.0/22 allow_proxy=True
-
-Allow an arbitrary subnet to use the Proxy
-------------------------------------------
-Since the default is to allow proxying, simply create the subnet in MAAS::
-
- $ maas admin subnets create cidr=192.168.100.0/23
-
-You may wish to set other parameters on the subnet.
-
-Disabling proxying
-------------------
-If you want to not use any proxy, see the Network Configuration section of
-the web user interface and uncheck the "Enable the use of an APT and HTTP/HTTPS
-proxy" box.
-
-.. image:: media/no-proxy.png
-
-Alternatively, the following command will disable the proxy::
-
- $ maas admin maas set-config name=enable_http_proxy value=False

=== removed file 'docs/rack-configuration.rst'
--- docs/rack-configuration.rst	2016-04-26 17:31:11 +0000
+++ docs/rack-configuration.rst	1970-01-01 00:00:00 +0000
@@ -1,192 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _rack-configuration:
-
-Rack Controller Configuration
-=============================
-
-Before any of MAAS's features can be used for the first time, you must have
-a Rack Controller and configure at least one VLAN to manage DHCP for at least
-a subnet. Each machine can be attached to any number of subnets, which may or
-may not be managed by MAAS.
-
-Managing a VLAN normally means that MAAS will server DHCP from the Rack
-Controller, for the purpose of providing IP address to machines that
-are being enlisted or commissioned. Also, any other DHCP client that is
-on the VLAN will obtain a dynamic IP address from the MAAS DHCP server.
-
-**Do this only on a network that was set up with this in mind**. Enabling
-your own DHCP server that competes with an existing one that's
-being managed by MAAS can cause serious disruption, and it can be hard
-for administrator to track the source of the problem.  Worse, the problems
-may not become immediately noticeable.  Make sure you understand the
-implications of running a DHCP server before doing this.  If MAAS detects any
-DHCP servers already running on these networks, it will show them on the
-rack's configuration page.
-
-
-Network requirements
---------------------
-
-The Rack Controller manages DHCP for subnet(s) in the VLAN(s) that it is
-connected to via one of its interfaces defined in MAAS. Rack Controller
-interfaces are discovered automatically, when MAAS is installed, and any
-future changes are automatically communicated to the region.
-
-When a Rack Controller manages machines on the network through one of the
-VLANs it is connected to, the machines must be in the same subnet as the
-Rack Controller interface connected to that VLAN. This is because:
-
-#. If the VLAN that the Rack Controller is connected to is configured to
-   provide DHCP, the nodes must be able to configure their own network
-   interfaces using MAAS's DHCP server. This means that either they must
-   be on the same subnet, or that DHCP packets are being specially routed
-   between the machine's subnet and MAAS' DHCP server.
-
-
-Registration
-------------
-
-If you install your first Rack Controller on the same system as the Region
-Controller, as is the case when you install the full "maas" ubuntu package,
-it will be automatically accepted by default (but not yet configured, see
-below).  Any other Rack Controllers you set up will show up automatically
-after they have been manually added to MAAS.
-
-To install a new MAAS Rack Controller, at the command line, type::
-
- $ sudo apt-get install maas-rack-controller
-
-Once installed, you will need to input the shared secret, in order
-to allow the Rack Controller to authenticate with the Region Controller.
-You can obtain the shared secret from the Region Controller. The
-shared secret can be copied from the Region Controller in::
-
- /var/lib/maas/secret
-
-Once you have copied the secret, you can install it in the Rack
-Controller. At the command line, type::
-
- $ sudo maas-rack install-shared-secret
-
-Once installed, you will need to reconfigure the Rack Controller
-to correctly point to the API hostname or IP address of the Region
-Controller that's on the same network as the Rack Controller::
-
- $ sudo dpkg-reconfigure maas-rack-controller
-
-The configuration for the MAAS Rack Controller will automatically
-run and pop up this config screen:
-
-.. image:: media/install_cluster-config.*
-
-This is where the MAAS Rack Controller is prompting for the URL
-of the MAAS Region Controller. Once entered, the Rack Controller
-configuration will be complete.
-
-
-Interface Management
---------------------
-
-MAAS automatically recognises the network interfaces on each Rack
-Controller.  Some (though not necessarily all) of these will be connected
-to subnets on a VLAN inside a Fabric. In other words, the Rack Controllers
-will be connected to VLANs, and the subnets being served on these.
-
-Once a new Rack Controller is connected, it will try to autodetect in
-what Subnet, VLAN and even Fabric the interface is connected to. If these
-have not being created, new Subnets, VLAN's and Fabrics and Spaces will
-be created.
-
-If Fabrics, VLANs and Subnets are already created, once MAAS automatically
-recognises the Rack Controller network interfaces, it will try to determine
-to which these are connected to before being able to provide services.
-
-As such, each Rack Controller interface will determine whether a Rack
-Controller can provide DHCP on an specific VLAN, or for advanced configuration,
-a Rack Controller interface will determine whether a Rack Controller
-can be a primary or backup Rack on an HA configuration.
-
-If for any reason, the Rack Controller interfaces are mis-identified
-and are in the correct fabric, the user can manually change that by
-editing the Rack Controller Fabric information:
-
-.. image:: media/rack-interface-edit.png
-
-
-In order for MAAS to be able to manage a machine throught its lifecycle,
-it needs to provide DHCP for at least one subnet, by configuring the
-corresponding VLAN to which the Rack Controller is connected to.
-
-
-Providing DHCP + HA
--------------------
-In order for MAAS to be able to manage machines on the network, and more
-specifically, in order to be able to enlist, commission and deploy machines
-it needs to provide and manage DHCP. As such, Rack Controller(s) can
-provide DHCP on the different VLANs it is connected to.
-
-Dynamic range & addresses
-^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting from MAAS 2.0, a Dynamic range needs to be defined in order for
-MAAS to be able to provide DHCP for machines. The purpose of the dynamic
-range is to:
-
- * provide DHCP for machines that are performing auto-registration (also
-   called enlistment), or
- * provide DHCP for machines that are being commissioned.
-
- This means that when a machine is being enlisted or commissioned, they
- DHCP from the dynamic range in order to perform those two steps.
-
- In turn, however, machines that are being deployed will, by default,
- obtain static IP addresses (DHCP or otherwise) from the section of the
- subnet that has not been reserved for the Dynamic Range on such VLAN.
- This allows the machine to obtain IP addresses that will remain
- allocated to a machine throughout the rest of its deployment.
-
-Enabling a DHCP on a VLAN (optional HA)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-As an example, we will configure MAAS to provide DHCP on a Rack
-Controller.
-
-The first thing that we need to do is select in what VLAN and subnet
-we would like to configure DHCP. In this case, in order to be able
-to PXE boot machines, we need to configure DHCP for an 'untagged' VLAN
-under any fabric. In this example, we will chose the 'untagged' VLAN on
-'fabric-0'. The subnet '192.168.10.0/24' is on this 'untagged' VLAN. We
-can see that the Rack Controller has access to this VLAN via its 'eth0'
-interface.
-
-The second step is to create a dynamic range::
-
- $ maas admin ipranges create type=dynamic start_ip=192.168.10.28 end_ip=192.168.10.100
-
-The third, and last step is to enable DHCP on a VLAN. For this to be
-effective we need to at least select the Primary Rack controller that will
-provide DHCP::
-
- $ maas admin vlan update fabric-0 untagged dhcp_on=True primary_rack=node01
-
-If enabling DHCP HA is something you need for your MAAS deployment, then
-following operation would enable HA::
-
- $ maas admin vlan update fabric-0 untagged dhcp_on=True primary_rack=node01 secondary_rack=node02
-
-Note that if you are enabling DHCP over the CLI, but the subnet doesn't have a
-Gateway IP defined, you can define the gateway using::
-
-  $ maas admin subnet update 192.168.10.0/24 gateway_ip=192.168.10.1
-
-You can also do the same configuration via the WebUI on the VLAN details page:
-
-.. image:: media/vlan_provide_dhcp.png
-
-
-Multiple networks
------------------
-
-A single Rack Controller can be connected to more than one VLAN, each from a
-different Rack Controller interface.  This allows one Rack Controller to
-manage different subnets to help scale your Rack Controller or to satisfy
-your network architecture.

=== modified file 'docs/releases.rst'
--- docs/releases.rst	2016-04-11 16:23:26 +0000
+++ docs/releases.rst	2017-02-28 15:11:34 +0000
@@ -1,62 +1,29 @@
+*************
 MAAS Releases
-=============
-
-
-MAAS currently has the following releases:
-
-
-1.5
----
-
-* Status: Deprecated.
-* Last release: 1.5.4
-* Location: ubuntu/trusty
-* Support:
-
-  * Release has been deprecated.
-  * No longer providing updates.
-  * Users need to upgrade to 1.7 or 1.9.
-
-
-1.7
----
-
-* Status: Old Stable Release
-* Current Release: 1.7.6
-* Location: ubuntu/trusty-updates
-* Support:
-
-  * It is currently only supported on Ubuntu trusty-updates.
-  * It will be supported until 1.9 series is SRU'd into Trusty.
-  * It will be deprecated once supreseeded by 1.9 around February 2016.
-
-
-1.8
----
-
-* Status: Deprecated
-* Initial release data: June 2015
-* Current release: 1.8.3
-* Location: No longer available
-* Support:
-
-  * Release has been deprecated.
-  * No longer providing updates.
-  * Users need to upgrade to 1.9.
-
+*************
+
+Stable Release
+==============
 
 1.9
 ---
 
+ * Status: Old Stable Release
+ * Latest version: 1.9.4
+ * Support: Ubuntu Trusty LTS. Only critical issues.
+
+2.1
+---
+
  * Status: Current Stable Release
- * Initial Release date: November 2015
- * Current release: 1.9.0
- * Location: ppa:maas/stable
- * Support: This will be an LTS release.
-
-
-2.0
+ * Latest version: 2.1.3
+ * Support: Ubuntu Xenial LTS.
+
+Development release
+===================
+
+2.2
 ---
 
- * Status: New Development Release
- * Estimated Release Date: March or April 2016
+ * Status: Current development release
+ * Localtion: ppa:maas/next

=== removed file 'docs/sstreams-mirror.rst'
--- docs/sstreams-mirror.rst	2016-10-17 20:43:34 +0000
+++ docs/sstreams-mirror.rst	1970-01-01 00:00:00 +0000
@@ -1,64 +0,0 @@
-Local Mirroring of Boot Images
-==============================
-
-Boot images are delivered to MAAS via the simplestreams protocol.  It is
-useful in some situations, such as testing, to mirror the images locally
-so that you don't need to repeatedly pull them down over a slower Internet
-link.
-
-First, install the required packages on the host where you wish to store
-the mirrored images::
-
-  $ sudo apt-get install simplestreams ubuntu-cloudimage-keyring apache2
-
-Now you can pull the images over using the mirroring tools for simplestreams.
-This example gets the daily trusty (14.04) and xenial (16.04) images for the
-amd64 architecture::
-
-  $ sudo sstream-mirror --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg https://images.maas.io/ephemeral-v3/daily/ /var/www/html/maas/images/ephemeral-v3/daily 'arch=amd64' 'release~(trusty|xenial)' --max=1
-
-This may take a while as hundreds of megabytes will be downloaded.
-
-As of MAAS 2.1 bootloaders are now included in the simplestream. In order for
-MAAS to work bootloaders must be mirrored as well. It is recommended that all
-bootloaders are mirrored::
-
-  $ sudo sstream-mirror --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg https://images.maas.io/ephemeral-v3/daily/ /var/www/html/maas/images/ephemeral-v3/daily 'os~(grub*|pxelinux)' --max=1
-
-The images will be written to the local disk and you can verify their
-presence by browsing to
-``http://<server>/maas/images/ephemeral-v3/daily/streams/v1/index.sjson``
-(replace ``<server>`` with your own server's name).
-
-It is a good idea to configure a ``cron`` job to repeat this import on a
-regular basis to keep your mirror up-to-date.
-
-
-Configuring MAAS to use the local mirror
-----------------------------------------
-
-You can do this using the API or the web UI.  To do this via the API you
-can use the ``maas`` (see :doc:`maascli`) command, logged in as the admin
-user::
-
-  $ maas <profile> boot-sources create url=http://<server>/images/ephemeral-v3/daily/ keyring_filename=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg
-
-Note that if you wish to use older images (which change far less frequently,
-but will be lacking security updates), you can use the ``releases`` stream,
-such as::
-
-  $ maas <profile> boot-sources create url=http://<server>/images/ephemeral-v3/releases/ keyring_filename=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg
-
-And then initiate the download with::
-
-  $ maas <profile> boot-resources import
-
-See :doc:`bootsources` for more detail.
-
-In the web UI, browse to the Settings tab as the admin user and scroll down
-to the "Boot Images" section.  There you will find input boxes for the
-Sync URL and the keyring path, which should be set as the values in the API
-example above.
-
-The import is initiated by browsing to the Images tab and following the
-instructions on that page.

=== removed file 'docs/static-ips.rst'
--- docs/static-ips.rst	2016-03-28 13:54:47 +0000
+++ docs/static-ips.rst	1970-01-01 00:00:00 +0000
@@ -1,53 +0,0 @@
-.. _static-ips:
-
-Static IPs
-==========
-
-.. note::
-
-  This feature is available in MAAS versions 1.6 and above.
-  If you're writing a client application, you can check if MAAS
-  supports this feature via the web API; see the documentation for the
-  ``static-ipaddresses`` capability :ref:`here<cap-static-ipaddresses>`.
-
-Previously, MAAS relied on the DHCP server to allocate its own IP
-addresses to nodes, using the IP range defined on the relevant cluster
-interface. This was found to be unreliable since the IPs were only known
-once the node had booted and requested an address, and had race conditions
-when the lease expired and another machine was looking for its own IP.
-
-MAAS now defines an additional range on the cluster for static IPs that
-are allocated by MAAS itself (see :doc:`rack-configuration` for more
-information about this).
-
-In normal operation, MAAS will automatically choose and allocate a static IP to
-any node network interfaces where it knows on which cluster interface that node
-interface is connected.
-
-The :doc:`api` contains functions to request additional static IPs, which are
-summarised here:
-
-Sticky IPs
-----------
-Synopsis:
-  ``POST /api/2.0/nodes/{system_id}/`` ``op=claim_sticky_ip_address``
-
-Normally, IPs are released back into the pool of available IPs once a node
-is released by a user.  A "Sticky" IP is one which is allocated to an interface
-on a node that does not change unless the sticky IP is removed.  This enables
-more predictable IPs at the cost of wasting IPs when the node is not in use.
-
-Unmanaged User-allocated IPs
-----------------------------
-Synopsis:
-  ``GET /api/2.0/ipaddresses/``
-
-  ``POST /api/2.0/ipaddresses/`` ``op=release``
-
-  ``POST /api/2.0/ipaddresses/`` ``op=reserve``
-
-This API allows users to request an ad-hoc IP address for use in any way they
-see fit.  The IP is not tied to any node in MAAS and is guaranteed not to be
-in use by MAAS itself.
-
-See the full :doc:`api` documentation for precise technical details.

=== removed file 'docs/storage.rst'
--- docs/storage.rst	2016-01-25 14:10:29 +0000
+++ docs/storage.rst	1970-01-01 00:00:00 +0000
@@ -1,679 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _storage:
-
-=========================
-Storage
-=========================
-
-.. note::
-
-  This feature is available in MAAS versions 1.9 and above on Ubuntu
-  deployments.  If you're writing a client application, you can check
-  if MAAS supports this feature via the web API; see the documentation
-  for the ``storage-deployment-ubuntu`` capability
-  :ref:`here<cap-storage-deployment-ubuntu>`.
-
-MAAS has the ability to configure any storage layout during node deployment.
-MAAS doesn't just do simple partitioning it supports complex storage layouts,
-including setting up and configuring Bcache, RAID, and LVM. This gives users
-unlimited possibilities on the storage configurations they want to deploy.
-
-Layouts
--------
-
-When a node is acquired by a user it gets a default storage layout. This layout
-provides the basic storage configuration to allow a node to deploy
-successfully. The default storage layout can also be adjusted allowing an
-administrator to make the decision on which layout will be the default.
-
-The users deploying nodes are not limited by the default. They can set an
-explicit storage layout when they acquire a node or after they have acquried a
-node with the set-storage-layout API. The user acquiring a node or performing
-the set-storage-layout API calls can also customize the layout generation. Each
-layout has a set of options that can be set to adjust the generated layout.
-
-Below list all the available storage layouts and the available options for
-each.
-
-LVM Layout
-^^^^^^^^^^
-
-Creates a volume group `vgroot` on a partition that spans the entire boot disk.
-A logical volume `lvroot` is created for the full size of the volume group. The
-`lvroot` is formatted with `ext4` and set as the `/` mount point.
-::
-
-    NAME        SIZE        TYPE    FSTYPE         MOUNTPOINT
-    sda         100G        disk
-      sda1      512M        part    fat32          /boot/efi
-      sda2      99.5G       part    lvm-pv(vgroot)
-    vgroot      99.5G       lvm
-      lvroot    99.5G       lvm     ext4           /
-
-The following options are supported for this layout.
-::
-
-    boot_size: Size of the boot partition on the boot disk. Default is 0,
-        meaning not to create the boot partition. The '/boot' will be placed
-        on the root filesystem.
-    root_device: The block device to place the root partition on. Default is
-        the boot disk.
-    root_size: Size of the root partition. Default is 100%, meaning the
-        entire size of the root device.
-    vg_name: Name of the created volume group. Default is `vgroot`.
-    lv_name: Name of the created logical volume. Default is `lvroot`.
-    lv_size: Size of the created logical volume. Default is 100%, meaning
-        the entire size of the volume group.
-
-Flat Layout
-^^^^^^^^^^^
-
-Creates a partition that spans the entire boot disk. The partition is formatted
-with `ext4` and set as the `/` mount point.
-::
-
-  NAME        SIZE        TYPE    FSTYPE         MOUNTPOINT
-  sda         100G        disk
-    sda1      512M        part    fat32          /boot/efi
-    sda2      99.5G       part    ext4           /
-
-The following options are supported for this layout.
-::
-
-  boot_size: Size of the boot partition on the boot disk. Default is 0,
-      meaning not to create the boot partition. The '/boot' will be placed
-      on the root filesystem.
-  root_device: The block device to place the root partition on. Default is
-      the boot disk.
-  root_size: Size of the root partition. Default is 100%, meaning the
-      entire size of the root device.
-
-Bcache Layout
-^^^^^^^^^^^^^
-
-Creates a Bcache using a partition that spans the entire boot disk as the
-backing device. Uses the smallest block device tagged with `ssd` as the cache
-device. The Bcache device is formatted with `ext4` and set as the `/` mount
-point. If no block devices exists on the node that are tagged with `ssd` then
-the Bcache device will not be created and the `flat` layout will be used.
-::
-
-  NAME        SIZE        TYPE    FSTYPE         MOUNTPOINT
-  sda         100G        disk
-    sda1      512M        part    fat32          /boot/efi
-    sda2      99.5G       part    bc-backing
-  sdb         50G         disk
-    sdb1      50G         part    bc-cache
-  bcache0     99.5G       disk    ext4           /
-
-The following options are supported for this layout.
-::
-
-  boot_size: Size of the boot partition on the boot disk. Default is 0,
-      meaning not to create the boot partition. The '/boot' will be placed
-      on the root filesystem.
-  root_device: The block device to place the root partition on. Default is
-      the boot disk.
-  root_size: Size of the root partition. Default is 100%, meaning the
-      entire size of the root device.
-  cache_device: The block device to use as the cache device. Default
-      is the smallest block device tagged ssd.
-  cache_mode: The cache mode to set the created Bcache device to. Default
-      is `writethrough`.
-  cache_size: The size of the partition on the cache device. Default is
-      100%, meaning the entire size of the cache device.
-  cache_no_part: Whether or not to create a partition on the cache device.
-      Default is false, meaning to create a partition using the given
-      `cache_size`. If set to true no partition will be created and the raw
-      cache device will be used as the cache.
-
-.. note::
-
-  The `/boot/efi` partition on all layouts will only be created on nodes that
-  deploy with UEFI.
-
-
-Setting the Layout
-------------------
-
-The following are a couple of was the storage layout can be changed either
-globally, on acquire, or after acquire.
-
-Globally
-^^^^^^^^
-
-The global default storage layout can be set using the API and the UI. This
-will change the default storage layout for when a node is acquired. `It will
-not adjust the layout of any node that is already passed the acquire stage.`::
-
-  $ maas my-maas-session maas set_config name=default_storage_layout value=flat
-
-Set Storage Layout
-^^^^^^^^^^^^^^^^^^
-
-If a node is already acquired and you want to adjust the storage layout the
-set_storage_layout API call can be used. The options for this API call do not
-require the `storage_layout_` prefix.::
-
-  $ maas my-maas-session node set-storage-layout <system-id> storage_layout=lvm lv_size=50%
-
-.. note::
-
-  This will completely remove any previous storage configuration on all block
-  devices.
-
-Block Devices
--------------
-
-Once the initial storage layout has been configure on a node you can perform
-many operations to view and adjust the entire storage layout for the node. In
-MAAS there are two different types of block devices.
-
-**Physical**
-
-A physical block device is a physically attached block device. This being true
-storage on a machine. E.g. A 100G hard drive in a server.
-
-**Virtual**
-
-A virtual block device is a block device that is exposed by the Linux kernel
-when an operation is performed. Almost all the operations on a physical block
-device can be performed on a virtual block device. E.g. A RAID device exposed
-as `md0`.
-
-List Block Devices
-^^^^^^^^^^^^^^^^^^
-To view all block devices on a node use the `read` operation. This list both
-physical and virtual block devices.::
-
-  $ maas my-maas-session block-devices read node-f4e2281c-d19a-11e4-a5ac-00163edde41f
-  [
-      {
-          "size": 21474836480,
-          "resource_uri": "/MAAS/api/2.0/nodes/node-f4e2281c-d19a-11e4-a5ac-00163edde41f/blockdevices/6/",
-          "uuid": null,
-          "tags": [
-              "ssd",
-              "rotary"
-          ],
-          "name": "sda",
-          "partition_table_type": "MBR",
-          "id_path": "/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001",
-          "path": "/dev/disk/by-dname/sda",
-          "model": "QEMU HARDDISK",
-          "block_size": 4096,
-          "type": "physical",
-          "id": 6,
-          "serial": "QM00001",
-          "partitions": [
-              {
-                  "uuid": "e94ca09a-d83e-4521-8bac-833da2ed0b3e",
-                  "bootable": false,
-                  "filesystem": {
-                      "label": null,
-                      "mount_point": null,
-                      "uuid": "61d447c2-387d-4fb1-885a-65eeef91e92a",
-                      "fstype": "lvm-pv"
-                  },
-                  "path": "/dev/disk/by-dname/sda-part1",
-                  "resource_uri": "/MAAS/api/2.0/nodes/node-f4e2281c-d19a-11e4-a5ac-00163edde41f/blockdevices/6/partition/1",
-                  "type": "partition",
-                  "id": 1,
-                  "size": 21471690752
-              }
-          ]
-      },
-      {
-          "resource_uri": "/MAAS/api/2.0/nodes/node-f4e2281c-d19a-11e4-a5ac-00163edde41f/blockdevices/11/",
-          "uuid": "f58b8fb2-dcf2-4ba9-a01c-60409829a64e",
-          "tags": [],
-          "partitions": [],
-          "name": "vgroot-lvroot",
-          "partition_table_type": null,
-          "filesystem": {
-              "label": "root",
-              "mount_point": "/",
-              "uuid": "9f09e3fd-2484-4da5-bb56-a72a0c478d06",
-              "fstype": "ext4"
-          },
-          "id_path": null,
-          "path": "/dev/disk/by-dname/lvroot",
-          "model": null,
-          "block_size": 4096,
-          "type": "virtual",
-          "id": 11,
-          "serial": null,
-          "size": 21470642176
-      }
-  ]
-
-Read Block Device
-^^^^^^^^^^^^^^^^^
-
-If you want to read just one block device instead of listing all block devices
-the `read` operation on the `block-device` endpoint provides that information.
-::
-
-  $ maas my-maas-session block-device read node-f4e2281c-d19a-11e4-a5ac-00163edde41f 12
-  {
-      "size": 21474836480,
-      "resource_uri": "/MAAS/api/2.0/nodes/node-f4e2281c-d19a-11e4-a5ac-00163edde41f/blockdevices/12/",
-      "uuid": null,
-      "tags": [],
-      "name": "sdb",
-      "partition_table_type": null,
-      "id_path": "",
-      "path": "/dev/disk/by-dname/sdb",
-      "model": "QEMU HARDDISK",
-      "block_size": 4096,
-      "type": "physical",
-      "id": 12,
-      "serial": "QM00001",
-      "partitions": []