Merge branch '15306-api-nonjson-params'

[arvados.git] / doc / admin / upgrading.html.textile.liquid

---
layout: default
navsection: admin
title: "Upgrading Arvados and Release notes"
...

{% comment %}
Copyright (C) The Arvados Authors. All rights reserved.

SPDX-License-Identifier: CC-BY-SA-3.0
{% endcomment %}

What you need to know and do in order to upgrade your Arvados installation.

h2. General process

# Wait for the cluster to be idle and stop Arvados services.
# Install new packages using @apt-get upgrade@ or @yum upgrade@.
# Package installation scripts will perform any necessary data migrations.
# Consult upgrade notes below to see if any manual configuration updates are necessary.
# Restart Arvados services.

h2. Upgrade notes

Some versions introduce changes that require special attention when upgrading: e.g., there is a new service to install, or there is a change to the default configuration that you might need to override in order to preserve the old behavior.

{% comment %}
Note to developers: Add new items at the top. Include the date, issue number, commit, and considerations/instructions for those about to upgrade.

TODO: extract this information based on git commit messages and generate changelogs / release notes automatically.
{% endcomment %}

h3. v1.4.0 (2019-06-05)

h4. Populating the new file_count and file_size_total columns on the collections table

As part of story "#14484":https://dev.arvados.org/issues/14484, two new columns were added to the collections table in a database migration. If your installation has a large collections table, this migration may take some time. We've seen it take ~5 minutes on an installation with 250k collections, but your mileage may vary.

The new columns are initialized with a zero value. In order to populate them, it is necessary to run a script called <code class="userinput">populate-file-info-columns-in-collections.rb</code> from the scripts directory of the API server. This can be done out of band, ideally directly after the API server has been upgraded to v1.4.0.

h4. Stricter collection manifest validation on the API server

As a consequence of "#14482":https://dev.arvados.org/issues/14482, the Ruby SDK does a more rigorous collection manifest validation. Collections created after 2015-05 are unlikely to be invalid, however you may check for invalid manifests using the script below.

You could set up a new rvm gemset and install the specific arvados gem for testing, like so:

<notextile>
<pre><code>~$ <span class="userinput">rvm gemset create rubysdk-test</span>
~$ <span class="userinput">rvm gemset use rubysdk-test</span>
~$ <span class="userinput">gem install arvados -v 1.3.1.20190301212059</span>
</code></pre>
</notextile>

Next, you can run the following script using admin credentials, it will scan the whole collection database and report any collection that didn't pass the check:

{% codeblock as ruby %}
require 'arvados'
require 'arvados/keep'

api = Arvados.new
offset = 0
batch_size = 100
invalid = []

while true
    begin
        req = api.collection.index(
            :select => [:uuid, :created_at, :manifest_text],
            :include_trash => true, :include_old_versions => true,
            :limit => batch_size, :offset => offset)
    rescue
        invalid.each {|c| puts "#{c[:uuid]} (Created at #{c[:created_at]}): #{c[:error]}" }
        raise
    end

    req[:items].each do |col|
        begin
            Keep::Manifest.validate! col[:manifest_text]
        rescue Exception => e
            puts "Collection #{col[:uuid]} manifest not valid"
            invalid << {uuid: col[:uuid], error: e, created_at: col[:created_at]}
        end
    end
    puts "Checked #{offset} / #{req[:items_available]} - Invalid: #{invalid.size}"
    offset += req[:limit]
    break if offset > req[:items_available]
end

if invalid.empty?
    puts "No invalid collection manifests found"
else
    invalid.each {|c| puts "#{c[:uuid]} (Created at #{c[:created_at]}): #{c[:error]}" }
end
{% endcodeblock %}

The script will return a final report enumerating any invalid collection by UUID, with its creation date and error message so you can take the proper correction measures, if needed.

h4. Python packaging change

As part of story "#9945":https://dev.arvados.org/issues/9945, the distribution packaging (deb/rpm) of our Python packages has changed. These packages now include a built-in virtualenv to reduce dependencies on system packages. We have also stopped packaging and publishing backports for all the Python dependencies of our packages, as they are no longer needed.

One practical consequence of this change is that the use of the Arvados Python SDK (aka "import arvados") will require a tweak if the SDK was installed from a distribution package. It now requires the loading of the virtualenv environment from our packages. The "Install documentation for the Arvados Python SDK":/sdk/python/sdk-python.html reflects this change. This does not affect the use of the command line tools (e.g. arv-get, etc.).

Python scripts that rely on the distribution Arvados Python SDK packages to import the Arvados SDK will need to be tweaked to load the correct Python environment.

This can be done by activating the virtualenv outside of the script:

<notextile>
<pre>~$ <code class="userinput">source /usr/share/python2.7/dist/python-arvados-python-client/bin/activate</code>
(python-arvados-python-client) ~$ <code class="userinput">path-to-the-python-script</code>
</pre>
</notextile>

Or alternatively, by updating the shebang line at the start of the script to:

<notextile>
<pre>
#!/usr/share/python2.7/dist/python-arvados-python-client/bin/python
</pre>
</notextile>

h4. python-arvados-cwl-runner deb/rpm package now conflicts with python-cwltool deb/rpm package

As part of story "#9945":https://dev.arvados.org/issues/9945, the distribution packaging (deb/rpm) of our Python packages has changed. The python-arvados-cwl-runner package now includes a version of cwltool. If present, the python-cwltool and cwltool distribution packages will need to be uninstalled before the python-arvados-cwl-runner deb or rpm package can be installed.

h4. Centos7 Python 3 dependency upgraded to rh-python35

As part of story "#9945":https://dev.arvados.org/issues/9945, the Python 3 dependency for Centos7 Arvados packages was upgraded from SCL python33 to rh-python35.

h4. Centos7 package for libpam-arvados depends on the python-pam package, which is available from EPEL

As part of story "#9945":https://dev.arvados.org/issues/9945, it was discovered that the Centos7 package for libpam-arvados was missing a dependency on the python-pam package, which is available from the EPEL repository. The dependency has been added to the libpam-arvados package. This means that going forward, the EPEL repository will need to be enabled to install libpam-arvados on Centos7.

h4. New configuration

Arvados is migrating to a centralized configuration file for all components.  During the migration, legacy configuration files will continue to be loaded.  See "Migrating Configuration":config-migration.html for details.

h3. v1.3.0 (2018-12-05)

This release includes several database migrations, which will be executed automatically as part of the API server upgrade. On large Arvados installations, these migrations will take a while. We've seen the upgrade take 30 minutes or more on installations with a lot of collections.

The @arvados-controller@ component now requires the /etc/arvados/config.yml file to be present. See <a href="{{ site.baseurl }}/install/install-controller.html#configuration">the @arvados-controller@ installation instructions</a>.

Support for the deprecated "jobs" API is broken in this release.  Users who rely on it should not upgrade.  This will be fixed in an upcoming 1.3.1 patch release, however users are "encouraged to migrate":upgrade-crunch2.html as support for the "jobs" API will be dropped in an upcoming release.  Users who are already using the "containers" API are not affected.

h3. v1.2.1 (2018-11-26)

There are no special upgrade notes for this release.

h3. v1.2.0 (2018-09-05)

h4. Regenerate Postgres table statistics

It is recommended to regenerate the table statistics for Postgres after upgrading to v1.2.0. If autovacuum is enabled on your installation, this script would do the trick:

<pre>
#!/bin/bash

set -e
set -u

tables=`echo "\dt" | psql arvados_production | grep public|awk -e '{print $3}'`

for t in $tables; do
    echo "echo 'analyze $t' | psql arvados_production"
    time echo "analyze $t" | psql arvados_production
done
</pre>

If you also need to do the vacuum, you could adapt the script to run 'vacuum analyze' instead of 'analyze'.

h4. New component: arvados-controller

Commit "db5107dca":https://dev.arvados.org/projects/arvados/repository/revisions/db5107dca adds a new system service, arvados-controller. More detail is available in story "#13496":https://dev.arvados.org/issues/13497.

To add the Arvados Controller to your system please refer to the "installation instructions":../install/install-controller.html after upgrading your system to 1.2.0.

Verify your setup by confirming that API calls appear in the controller's logs (_e.g._, @journalctl -fu arvados-controller@) while loading a workbench page.

h3. v1.1.4 (2018-04-10)

h4. arvados-cwl-runner regressions (2018-04-05)

<strong>Secondary files missing from toplevel workflow inputs</strong>

This only affects workflows that rely on implicit discovery of secondaryFiles.

If a workflow input does not declare @secondaryFiles@ corresponding to the @secondaryFiles@ of workflow steps which use the input, the workflow would inconsistently succeed or fail depending on whether the input values were specified as local files or referenced an existing collection (and whether the existing collection contained the secondary files or not).  To ensure consistent behavior, the workflow is now required to declare in the top level workflow inputs any secondaryFiles that are expected by workflow steps.

As an example, the following workflow will fail because the @toplevel_input@ does not declare the @secondaryFiles@ that are expected by @step_input@:

<pre>
class: Workflow
cwlVersion: v1.0
inputs:
  toplevel_input: File
outputs: []
steps:
  step1:
    in:
      step_input: toplevel_input
    out: []
    run:
      id: sub
      class: CommandLineTool
      inputs:
        step_input:
          type: File
          secondaryFiles:
            - .idx
      outputs: []
      baseCommand: echo
</pre>

When run, this produces an error like this:

<pre>
cwltool ERROR: [step step1] Cannot make job: Missing required secondary file 'hello.txt.idx' from file object: {
    "basename": "hello.txt",
    "class": "File",
    "location": "keep:ade9d0e032044bd7f58daaecc0d06bc6+51/hello.txt",
    "size": 0,
    "nameroot": "hello",
    "nameext": ".txt",
    "secondaryFiles": []
}
</pre>

To fix this error, add the appropriate @secondaryFiles@ section to @toplevel_input@

<notextile>
<pre><code>class: Workflow
cwlVersion: v1.0
inputs:
  <span class="userinput">toplevel_input:
    type: File
    secondaryFiles:
      - .idx</span>
outputs: []
steps:
  step1:
    in:
      step_input: toplevel_input
    out: []
    run:
      id: sub
      class: CommandLineTool
      inputs:
        step_input:
          type: File
          secondaryFiles:
            - .idx
      outputs: []
      baseCommand: echo
</code></pre>
</notextile>

This bug has been fixed in Arvados release v1.2.0.

<strong>Secondary files on default file inputs</strong>

@File@ inputs that have default values and also expect @secondaryFiles@ and will fail to upload default @secondaryFiles@.  As an example, the following case will fail:

<pre>
class: CommandLineTool
inputs:
  step_input:
    type: File
    secondaryFiles:
      - .idx
    default:
      class: File
      location: hello.txt
outputs: []
baseCommand: echo
</pre>

When run, this produces an error like this:

<pre>
2018-05-03 10:58:47 cwltool ERROR: Unhandled error, try again with --debug for more information:
  [Errno 2] File not found: u'hello.txt.idx'
</pre>

To fix this, manually upload the primary and secondary files to keep and explicitly declare @secondaryFiles@ on the default primary file:

<notextile>
<pre><code>class: CommandLineTool
inputs:
  step_input:
    type: File
    secondaryFiles:
      - .idx
    <span class="userinput">default:
      class: File
      location: keep:4d8a70b1e63b2aad6984e40e338e2373+69/hello.txt
      secondaryFiles:
       - class: File
         location: keep:4d8a70b1e63b2aad6984e40e338e2373+69/hello.txt.idx</span>
outputs: []
baseCommand: echo
</code></pre>
</notextile>

This bug has been fixed in Arvados release v1.2.0.

h3. v1.1.3 (2018-02-08)

There are no special upgrade notes for this release.

h3. v1.1.2 (2017-12-22)

h4. The minimum version for Postgres is now 9.4 (2017-12-08)

As part of story "#11908":https://dev.arvados.org/issues/11908, commit "8f987a9271":https://dev.arvados.org/projects/arvados/repository/revisions/8f987a9271 introduces a dependency on Postgres 9.4. Previously, Arvados required Postgres 9.3.

* Debian 8 (pg 9.4) and Debian 9 (pg 9.6) do not require an upgrade
* Ubuntu 16.04 (pg 9.5) does not require an upgrade
* Ubuntu 14.04 (pg 9.3) requires upgrade to Postgres 9.4: https://www.postgresql.org/download/linux/ubuntu/
* CentOS 7 and RHEL7 (pg 9.2) require upgrade to Postgres 9.4. It is necessary to migrate of the contents of your database: https://www.postgresql.org/docs/9.0/static/migration.html
*# Create a database backup using @pg_dump@
*# Install the @rh-postgresql94@ backport package from either Software Collections: http://doc.arvados.org/install/install-postgresql.html or the Postgres developers: https://www.postgresql.org/download/linux/redhat/
*# Restore from the backup using @psql@

h3. v1.1.1 (2017-11-30)

There are no special upgrade notes for this release.

h3. v1.1.0 (2017-10-24)

h4. The minimum version for Postgres is now 9.3 (2017-09-25)

As part of story "#12032":https://dev.arvados.org/issues/12032, commit "68bdf4cbb1":https://dev.arvados.org/projects/arvados/repository/revisions/68bdf4cbb1 introduces a dependency on Postgres 9.3. Previously, Arvados required Postgres 9.1.

* Debian 8 (pg 9.4) and Debian 9 (pg 9.6) do not require an upgrade
* Ubuntu 16.04 (pg 9.5) does not require an upgrade
* Ubuntu 14.04 (pg 9.3) is compatible, however upgrading to Postgres 9.4 is recommended: https://www.postgresql.org/download/linux/ubuntu/
* CentOS 7 and RHEL7 (pg 9.2) should upgrade to Postgres 9.4. It is necessary to migrate of the contents of your database: https://www.postgresql.org/docs/9.0/static/migration.html
*# Create a database backup using @pg_dump@
*# Install the @rh-postgresql94@ backport package from either Software Collections: http://doc.arvados.org/install/install-postgresql.html or the Postgres developers: https://www.postgresql.org/download/linux/redhat/
*# Restore from the backup using @psql@

h3. Older versions

h4. Upgrade slower than usual (2017-06-30)

As part of story "#11807":https://dev.arvados.org/issues/11807, commit "55aafbb":https://dev.arvados.org/projects/arvados/repository/revisions/55aafbb converts old "jobs" database records from YAML to JSON, making the upgrade process slower than usual.

* The migration can take some time if your database contains a substantial number of YAML-serialized rows (i.e., you installed Arvados before March 3, 2017 "660a614":https://dev.arvados.org/projects/arvados/repository/revisions/660a614 and used the jobs/pipelines APIs). Otherwise, the upgrade will be no slower than usual.
* The conversion runs as a database migration, i.e., during the deb/rpm package upgrade process, while your API server is unavailable.
* Expect it to take about 1 minute per 20K jobs that have ever been created/run.

h4. Service discovery overhead change in keep-web (2017-06-05)

As part of story "#9005":https://dev.arvados.org/issues/9005, commit "cb230b0":https://dev.arvados.org/projects/arvados/repository/revisions/cb230b0 reduces service discovery overhead in keep-web requests.

* When upgrading keep-web _or keepproxy_ to/past this version, make sure to update API server as well. Otherwise, a bad token in a request can cause keep-web to fail future requests until either keep-web restarts or API server gets upgraded.

h4. Node manager now has an http endpoint for management (2017-04-12)

As part of story "#11349":https://dev.arvados.org/issues/11349, commit "2c094e2":https://dev.arvados.org/projects/arvados/repository/revisions/2c094e2 adds a "management" http server to nodemanager.

* To enable it, add to your configuration file: <pre>[Manage]
  address = 127.0.0.1
  port = 8989</pre> (see example configuration files in source:services/nodemanager/doc or https://doc.arvados.org/install/install-nodemanager.html for more info)
* The server responds to @http://{address}:{port}/status.json@ with a summary of how many nodes are in each state (booting, busy, shutdown, etc.)

h4. New websockets component (2017-03-23)

As part of story "#10766":https://dev.arvados.org/issues/10766, commit "e8cc0d7":https://dev.arvados.org/projects/arvados/repository/revisions/e8cc0d7 replaces puma with arvados-ws as the recommended websocket server.
* See http://doc.arvados.org/install/install-ws.html for install/upgrade instructions.
* Remove the old puma server after the upgrade is complete. Example, with runit: <pre>
$ sudo sv down /etc/sv/puma
$ sudo rm -r /etc/sv/puma
</pre> Example, with systemd: <pre>
$ systemctl disable puma
$ systemctl stop puma
</pre>

h4. Change of database encoding for hashes and arrays (2017-03-06)

As part of story "#11168":https://dev.arvados.org/issues/11168, commit "660a614":https://dev.arvados.org/projects/arvados/repository/revisions/660a614 uses JSON instead of YAML to encode hashes and arrays in the database.

* Aside from a slight performance improvement, this should have no externally visible effect.
* Downgrading past this version is not supported, and is likely to cause errors. If this happens, the solution is to upgrade past this version.
* After upgrading, make sure to restart puma and crunch-dispatch-* processes.

h4. Docker image format compatibility check (2017-02-03)

As part of story "#10969":https://dev.arvados.org/issues/10969, commit "74a9dec":https://dev.arvados.org/projects/arvados/repository/revisions/74a9dec introduces a Docker image format compatibility check: the @arv keep docker@ command prevents users from inadvertently saving docker images that compute nodes won't be able to run.
* If your compute nodes run a version of *docker older than 1.10* you must override the default by adding to your API server configuration (@/etc/arvados/api/application.yml@): <pre><code class="yaml">docker_image_formats: ["v1"]</code></pre>
* Refer to the comments above @docker_image_formats@ in @/var/www/arvados-api/current/config/application.default.yml@ or source:services/api/config/application.default.yml or issue "#10969":https://dev.arvados.org/issues/10969 for more detail.
* *NOTE:* This does *not* include any support for migrating existing Docker images from v1 to v2 format. This will come later: for now, sites running Docker 1.9 or earlier should still *avoid upgrading Docker further than 1.9.*

h4. Debian and RPM packages now have systemd unit files (2016-09-27)

Several Debian and RPM packages -- keep-balance ("d9eec0b":https://dev.arvados.org/projects/arvados/repository/revisions/d9eec0b), keep-web ("3399e63":https://dev.arvados.org/projects/arvados/repository/revisions/3399e63), keepproxy ("6de67b6":https://dev.arvados.org/projects/arvados/repository/revisions/6de67b6), and arvados-git-httpd ("9e27ddf":https://dev.arvados.org/projects/arvados/repository/revisions/9e27ddf) -- now enable their respective components using systemd. These components prefer YAML configuration files over command line flags ("3bbe1cd":https://dev.arvados.org/projects/arvados/repository/revisions/3bbe1cd).

* On Debian-based systems using systemd, services are enabled automatically when packages are installed.
* On RedHat-based systems using systemd, unit files are installed but services must be enabled explicitly: e.g., <code>"sudo systemctl enable keep-web; sudo systemctl start keep-web"</code>.
* The new systemd-supervised services will not start up successfully until configuration files are installed in /etc/arvados/: e.g., <code>"Sep 26 18:23:55 62751f5bb946 keep-web[74]: 2016/09/26 18:23:55 open /etc/arvados/keep-web/keep-web.yml: no such file or directory"</code>
* To migrate from runit to systemd after installing the new packages, we recommend the following procedure:
*# Bring down the runit service: "sv down /etc/sv/keep-web"
*# Create a JSON configuration file (e.g., /etc/arvados/keep-web/keep-web.yml -- see "keep-web -help")
*# Ensure the service is running correctly under systemd: "systemctl status keep-web" / "journalctl -u keep-web"
*# Remove the runit service so it doesn't start at next boot
* Affected services:
** keep-balance - /etc/arvados/keep-balance/keep-balance.yml
** keep-web - /etc/arvados/keep-web/keep-web.yml
** keepproxy - /etc/arvados/keepproxy/keepproxy.yml
** arvados-git-httpd - /etc/arvados/arv-git-httpd/arv-git-httpd.yml

h4. Installation paths for Python modules and script changed (2016-05-31)

Commits "ae72b172c8":https://dev.arvados.org/projects/arvados/repository/revisions/ae72b172c8 and "3aae316c25":https://dev.arvados.org/projects/arvados/repository/revisions/3aae316c25 change the filesystem location where Python modules and scripts are installed.

* Previous packages installed these files to the distribution's preferred path under @/usr/local@ (or the equivalent location in a Software Collection).  Now they get installed to a path under @/usr@.  This improves compatibility with other Python packages provided by the distribution.  See "#9242":https://dev.arvados.org/issues/9242 for more background.
* If you simply import Python modules from scripts, or call Python tools relying on $PATH, you don't need to make any changes.  If you have hardcoded full paths to some of these files (e.g., in symbolic links or configuration files), you will need to update those paths after this upgrade.

h4. Crunchrunner package is required on compute and shell nodes (2016-04-25)

Commit "eebcb5e":https://dev.arvados.org/projects/arvados/repository/revisions/eebcb5e requires the crunchrunner package to be installed on compute nodes and shell nodes in order to run CWL workflows.

* On each Debian-based compute node and shell node, run: @sudo apt-get install crunchrunner@
* On each Red Hat-based compute node and shell node, run: @sudo yum install crunchrunner@

h4. Keep permission signature algorithm change (2016-04-21)

Commit "3c88abd":https://dev.arvados.org/projects/arvados/repository/revisions/3c88abd changes the Keep permission signature algorithm.

* All software components that generate signatures must be upgraded together. These are: keepstore, API server, keep-block-check, and keep-rsync. For example, if keepstore < 0.1.20160421183420 but API server >= 0.1.20160421183420, clients will not be able to read or write data in Keep.
* Jobs and client operations that are in progress during the upgrade (including arv-put's "resume cache") will fail.

h4. Workbench's "Getting Started" popup disabled by default (2015-01-05)

Commit "e1276d6e":https://dev.arvados.org/projects/arvados/repository/revisions/e1276d6e disables Workbench's "Getting Started" popup by default.

* If you want new users to continue seeing this popup, set @enable_getting_started_popup: true@ in Workbench's @application.yml@ configuration.

h4. Crunch jobs now have access to Keep-backed writable scratch storage (2015-12-03)

Commit "5590c9ac":https://dev.arvados.org/projects/arvados/repository/revisions/5590c9ac makes a Keep-backed writable scratch directory available in crunch jobs (see "#7751":https://dev.arvados.org/issues/7751)

* All compute nodes must be upgraded to arvados-fuse >= 0.1.2015112518060 because crunch-job uses some new arv-mount flags (--mount-tmp, --mount-by-pdh) introduced in merge "346a558":https://dev.arvados.org/projects/arvados/repository/revisions/346a558
* Jobs will fail if the API server (in particular crunch-job from the arvados-cli gem) is upgraded without upgrading arvados-fuse on compute nodes.

h4. Recommended configuration change for keep-web (2015-11-11)

Commit "1e2ace5":https://dev.arvados.org/projects/arvados/repository/revisions/1e2ace5 changes recommended config for keep-web (see "#5824":https://dev.arvados.org/issues/5824)

* proxy/dns/ssl config should be updated to route "https://download.uuid_prefix.arvadosapi.com/" requests to keep-web (alongside the existing "collections" routing)
* keep-web command line adds @-attachment-only-host download.uuid_prefix.arvadosapi.com@
* Workbench config adds @keep_web_download_url@
* More info on the (still beta/non-TOC-linked) "keep-web doc page":http://doc.arvados.org/install/install-keep-web.html

h4. Stopped containers are now automatically removed on compute nodes (2015-11-04)

Commit "1d1c6de":https://dev.arvados.org/projects/arvados/repository/revisions/1d1c6de removes stopped containers (see "#7444":https://dev.arvados.org/issues/7444)

* arvados-docker-cleaner removes _all_ docker containers as soon as they exit, effectively making @docker run@ default to @--rm@. If you run arvados-docker-cleaner on a host that does anything other than run crunch-jobs, and you still want to be able to use @docker start@, read the "new doc page":http://doc.arvados.org/install/install-compute-node.html to learn how to turn this off before upgrading.

h4. New keep-web service (2015-11-04)

Commit "21006cf":https://dev.arvados.org/projects/arvados/repository/revisions/21006cf adds a new keep-web service (see "#5824":https://dev.arvados.org/issues/5824).

* Nothing relies on keep-web yet, but early adopters can install it now by following http://doc.arvados.org/install/install-keep-web.html (it is not yet linked in the TOC).