HowTo_ja.txt

Metaplugin CI システム構築 Howto

注: まだ、実際の構築前のメモ。構築後、実際の環境を反映して、修正する。

○ 内容

- 事前準備
- master 初期構築
- master 更新
- slave 初期構築
- slave 更新
- log server 構築
- 実装メモ

○ 事前準備

以下のマシンが必要。

- master
  jenkinsのmasterノード用。zuul も稼働。1台。
- slave
  jenkinsのslaveノード用。実際のテストが実行される。数台。
- log server
  実行ログの格納、公開用。1台。(masterとの兼用可)

(以下、log server の構築については、未稿)

・マシンスペック
  master:
    メモリ:    2G
    ディスク: 10G

  slave:
    メモリ:    4G
    ディスク: 40G

・OS
  Ubuntu 14.04
  (注: puppetのmanifestがubuntu前提で作成されているため、ubuntuでなければならない。
       現状、14.04 で動作確認。)

・ネットワーク環境
  - master
    internatにアクセスできる必要あり。(どこかのgateway経由のSNATで構わない。外部から
    アクセスできる必要はない。)
    ただし、jenkins の管理web画面の操作は行う必要があるため、管理者の環境から、master
    へのアクセスは確保する必要がある。(構築作業等、コンソールからでは不便なので、管理
    者の環境から、SSHアクセスできる必要がある。)
  - slave
    master、log-server との通信ができればよい。
    (管理者からの操作は、直接できなくとも、master経由で構わない)
  - log-server
    ログを公開するため、外部からアクセスできる必要がある。
    maseter、slave 間の通信も当然必要。
    (管理者からの操作は、直接できなくとも、master経由で構わない)

・OSインストールと設定
  - 管理ユーザ
    ユーザ名は各マシンで統一しておく。(仮に ciuser とする)
  - インストール時は、SSHサービスを有効にする。
  - /etc/hosts
    master、slave、log server が名前解決できるよう、/etc/hostsに記述しておく。
    --- 例 ---
    192.168.122.10 master zuul    (<= zuul が必要らしい。詳細未確認)
    192.168.122.21 slave1
    192.168.122.22 slave2
    192.168.122.1  log-server
    ----------
    注: 固定IPアドレスを前提。
  - 管理ユーザは、各マシンに公開鍵でSSHログインできるようにしておく。
    注: 構築スクリプトを実行すると、公開鍵ログインしかできなくなるため、事前に準備して
        おく。
  - SCP用ユーザ
    slaveからlog-serverにログをSCP転送する際に使用するユーザが必要。管理ユーザ(ciuser)
    でもOK。

○ master 初期構築

(注: masterの構築を最初に行う必要がある。)

1) 構築用ディレクトリ作成
   作業用のディレクトリを作成し、以降の作業は、そこをカレントディレクトリとして行う。
   ---
   $ pwd
   /home/ciuser
   $ mkdir cibuild
   $ cd cibuild
   ---

2) metaplugin-ci リポジトリのclone
   ---
   $ sudo apt-get install git  (<= 多分必要)
   ...
   $ git clone https://github.com/ntt-sic/metaplugin-ci
   ...
   ---

3) data ディレクトリとその中身の用意
   ---
   $ mkdir data
   ---

   必要なものは、以下のとおり。
   - vars.sh         各種環境変数定義
   - gerrit_key      gerritにアクセスする際のプライベートキー
   - jenkins_key     master/slave間のアクセス用(プライベートキー)
   - jenkins_key.pub master/slave間のアクセス用(パブリックキー)

   ・vars.sh
     ほぼ固定の内容。metaplugin-ci/data-template/vars.sh をコピーし、必要な箇所を
     編集する。
     ---
     $ cp metaplugin-ci/data-template/vars.sh data
     $ vi data/vars.sh
     ---

     vars.sh の内容は以下のとおり。(★: 現状は、テスト用のものが入っているが、本番
     環境構築時には、固定で、編集の必要はなくなる予定。)
     - UPSTREAM_GERRIT_HOST_PUBLIC_KEY
       gerritサーバの公開鍵の内容。
     - GIT_EMAIL
       gitアカウント用e-mailアドレス
     - GIT_NAME
       サーアパーティCI用ユーザ名
     - UPSTREAM_GERRIT_SERVER
       gerritサーバ
     - UPSTREAM_GERRIT_USER
       Metaplugin CI 用に取得したユーザ名
     - LOG_URL_BASE
       ログサーバにログを転送する際のベースURL
       (ex. http://<ip address>/metaplugin-ci)
     - LOG_SERVER
       ログサーバのホスト名(/etc/hosts に書いたホスト名と一致させる)
     - JENKINS_URL
       slaveからmasterにアクセスする際のURL。(http://master:8080/ 固定でよい)
     - ZUUL_URL
       ?

   ・gerrit_key
     これは、Metaplugin CI用に取得したプライベートキーをこのファイル名で置く。

   ・jenkins_key、jenkins_key.pub
     master/slave間のアクセスに使用するキーペアを用意する。なければ、以下のように作成
     する。ファイル名は、jenkins_key、jenkins_key.pub にする。
     ---
     $ cd data
     $ ssh-keygen -t rsa -b 1024 -N '' -f jenkins_key
     $ cd ..
     ---

4) master構築スクリプト実行
   ---
   $ sudo bash metaplugin-ci/tools/install_master.sh
   ...
   ---

   install_master.sh は、下記を実行する。

   a) openstack-infra/config リポジトリのclone
      /opt/config に cloneする。
      openstack-infra/config の manifest、install スクリプトを使用するため。
   b) puppetのインストール
      /opt/config/install_puppet.sh の実行。
      puppet環境のインストール。
   c) moduleのインストール
      /opt/config/install_modules.sh の実行。
      結構、WarningとErrorが出る。Warningは気にしない。Errorは、「already installed」
      であれば気にしない。スクリプトは、エラーが起きても停止しない。
   d) apache用certファイル作成
      (注: 必要性がよく分かっていない)
   e) Metaplugin CI masterノード構築用manifest適用
      jenkins、zuul 関連の設定を行う。
      Warningが少し出るが気にしない。

   a)～d) は初回のみ実行される。
   何か変更があるときは、metaplugin/modules/metaplugin_ci の下を修正し、manifestの再適用
   (eの部分)を行う。このときも、install_master.sh を実行すればよい。

5) サービスの起動
   ---
   $ sudo a2enmod cgid               (<= CGIを有効にする必要あり)
   $ sudo service apache2 restart
   $ sudo service jenkins restart    (動いてるかもしれないので、restart)
   $ sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/
   (jenkinsの初期化がきちんと終わっていないと失敗するので、jenkins の
    startから少し時間を置く)
   $ sudo service zuul start
   $ sudo service zuul-merget start
   (zuul、zuul-merger がきちんと動いていることを確認する。
    $ sudo service zuul status
    $ sudo service zuul-merger status )
   ---

6) jenkinsの設定
  jenkinsのWeb画面(http://master:8080/)に接続して、設定を行う。

  a) geaman plugin の有効化
    [Mangege Jenkins] -> [Configure System]
    画面をスクロールし、[Gearman Plugin Config]のところ。
    - [Test Connection] ボタンを押して、接続を確認
      注: zuul が起動している必要がある。(geaman serverは、zuulが起動する)
    - [Enable Geaman] チェックボックスにチェックを入れる。
    - 画面下の[Save]ボタンを押下

  b) credentialの登録
    [Credentials] -> [Global credentials] -> [Add Credentials]
    以下のように設定。
    * Kind: SSH Username with private key
    * Scope: Global
    * Username: jenkins
    * Description: 空でよい
    * Privatekey: [From a file on Jnekins master] にチェック
        File: /var/lib/jenkins/.ssh/id_rsa
    [OK]ボタンを押下

  c) SCPの設定
    ログサーバへの転送に使用される。
    [Manage Jenkins] -> [Configure System]
    画面をスクロールし、[SCP repository hosts]のところ。
    以下のように設定。
    * Displayname: vars.sh の LOG_SERVER と一致させる。
    * Hostname: vars.sh の LOG_SERVER と一致させる。(つまり、DisplaynameとHostnameは同じ)
    * Port: 22
    * Root Repository Path: ログサーバ側の格納ディレクトリ。
      (ex. /var/www/html/metaplugin-ci)
      (vars.sh の LOG_URL_BASE でアクセスされる場所と一致していること。)
    * User Name: SCP用ユーザ(ciuserを使用してもよい)
    * Passward/Passphrase: SCP用ユーザのパスワード
    * Keyfile: PasswardかKeyfileのどちらかを使用する。Passwardの方が設定が簡単。
    画面下の[Save]ボタンを押下。

    (注: ログサーバの構築を先にしておかないといけないかも)

補足) zuul status 画面
  http://master:80/ にアクセスすると、zuul の status 画面が出せる。キューの状況を
  確認できる。
  /etc/apache2/apache2.conf <Directory /> のところ、Require all granted にする
  必要あり。(その意味、未確認)

○ master 更新

  更新が必要な場合は、metaplugin-ci 配下を修正し、install_master.sh を実行する。
  (github の方に commit しておくこと。)
  ---
  $ cd cibuild
  $ metaplugin-ci/ 配下の修正
  $ sudo bash metaplugin-ci/tools/install_master.sh
  ---

  更新の種類により、以下の追加作業を行う。

  ・jenkins の構成に変更がある場合(ex. pluginの追加、更新)
    ---
    $ sudo service jenkins restart
    ---
    必要であれば、jenkins の管理Web画面で、plugin関連の設定を行う。

  ・jobの定義に変更がある場合(i.e. /etc/jenkins-jobs/config/配下の修正)
    ---
    $ sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/
    ---
    (jenkinsのrestartは必要ない)

  ・layout.yaml に変更がある場合
    ---
    $ sudo service zuul reload
    ---
    注: stop/start すると、queueが消えてしまうので、reload する。
    注: zuul-merger の方は、reload/restartする必要なし。

○ slave 初期構築

1) master構築時に使用した、cibuild/data を使用する。cibuild ごと、master より SCPする。
   ---
   $ pwd
   /home/ciuser
   $ scp -r master:/home/ciuser/cibuild .
   ---
   補足: master/home/ciuser/cibuild を NFS マウントするのでもよい。

2) 構築スクリプト実行
   ---
   $ sudo apt-get install git  (<= 多分、必要)
   $ cd cubuild
   $ sudo bash metaplugin-ci/tools/install_slave.sh
   ...
   ---

   install_slave.sh は、下記を実行する。

   a) openstack-infra/config リポジトリのclone
      /opt/config に cloneする。
      openstack-infra/config の manifest、install スクリプトを使用するため。
   b) puppetのインストール
      /opt/config/install_puppet.sh の実行。
      puppet環境のインストール。
   c) moduleのインストール
      /opt/config/install_modules.sh の実行。
   d) Metaplugin CI slaveノード構築用manifest適用
      jenkins slaveとしての設定を行う。
   e) devstack実行環境準備
      /opt/git の下に、あらゆるリポジトリをcloneする。

   a)～c)については、master ノードと同様。
   a)～c)、e) は初回構築時のみ実行される。

   補足: d)は(初回は)結構時間がかかる。e) はかなり時間かかる。

3) slaveの登録
  jenkinsの管理Web画面から。
  [Manage Jenkins] -> [Manage Nodes] -> [New Node]
  以下のように設定。
  * Node name: slaveのホスト名(/etc/hostsに書いたもの)
  * Dumb Slave にチェック。
  (Copy Existing Node にはチェックしない)
  [OK]ボタン押下 -> 次の画面が出る。以下のように設定。
  * Name: ホスト名
  * Description: 空でよい
  * # of executors: 1
  * Remote root directory: /home/jenkins/workspaces
  * Labels: devstack_slave
  * Usage: Utilize this node as much as possible
  * Launch method: Launch slave agents on Unix machines via SSH
        Host: <slaveのip address>
        Credentials: jenkins
  [Save]ボタン押下(画面の下の方にある)

  しばらくすると、Webのトップ画面に追加したslaveが出て、onlineになる。

○ slave 更新

  更新が必要な場合は、metaplugin-ci 配下を修正し、install_slave.sh を実行する。
  (github の方に commit しておくこと。)
  ---
  $ cd cibuild
  $ metaplugin-ci/ 配下の修正
  $ sudo bash metaplugin-ci/tools/install_slave.sh
  ---

○ log server 構築

1) 公開用ディレクトリの作成
  jenkins の SCP設定画面で、[Root Repository Path] に設定するもの。
  [SCP User] の書き込み権があるようにしておくこと。

2) apache の設定については、未。

  (テスト環境では、
   $ sudo mkdir /var/www/html/metaplugin-ci
   $ sudo chown ciuser /var/www/html/metaplugin-ci
   $ sudo chgrp ciuser /var/www/html/metaplugin-ci
   としたのみ。)

○ 実装メモ

まだ書いている最中。metaplugin-ci の内容の説明。

・参考システム
  metaplugin-ci は以下を参考に作成した。
  1) Jay Pipes さんのサードパーティテストシステム構成記事とリポジトリ
    https://github.com/jaypipes/os-ext-testing.git
    https://github.com/jaypipes/os-ext-testing-data.git
    http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
    http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/
  2) Ryu のサードパーティテストシステム
    https://github.com/osrg/ryu-neutron-zuul-ci
  3) openstack-infra の各種リポジトリ
    https://github.com/openstack-infra/config
    https://github.com/openstack-infra/devstack-gate 

・metaplugin-ci の概要
  puppet を使用し、jenkins の masterノードと slaveノードの構築・設定を行うもの。
  jenkinsに関しては、JJB(jenkins job builder)を使用してjob定義を行い、zuul と連携して、
  jobを実行するため、masterノードに関しては、JJBやzuulの構築・設定も含まれている。

  job定義については、言うまでもなく、サードパーティテスティングを行うためのjobを定義する。
  gerrit からの通知をトリガーに job を起動し、結果を返すといった一連の流れを制御するため
  に zuul を使用している。
  openstackインフラで実行されている、check job や gate job も同じ仕組みであり、その
  ミニチュア版といったところである。(puppetのmanifestについても、openstack インフラのもの
  を利用している。)

  puppet および、構築対象である jenkins、JJB、zuul の知識があれば、「大したことはやって
  いない」ことが分かる(はずである。筆者はまだよく分かっていない)。
  何をやっているか、よく分からない場合は、それらを地道に勉強するとよい。

  - puppet
    https://docs.puppetlabs.com/puppet/
  - JJB
    http://ci.openstack.org/jenkins-job-builder/index.html   
  - zuul
    http://ci.openstack.org/zuul/index.html

・参考システムとの関係
  基本的には、Jay Pipes さんの os-ext-testing をベースにしている。os-ext-testingでは、
  2つのpuppet module を定義している。
  - os_ext_testing
  - jenkins
  os-ext-testing は、masterノードとslaveノード構築用のmanifestが定義されており、肝の
  部分。
  jenkinsは、jenkins関係の構築・設定用のmanifestが定義されている。openstack-infra/config
  にも同様のものがあり、zuul に関しては、openstack-infra/config のものを使用している。
  jenkinsについて、なぜ独自に持っているかは不明。(恐らく、現在ではその必要はなくなってい
  ると思われる。os-ext-testingは、2014年2月頃のもので、更新されていない。)
  metaplugin-ci では、jenkinsについても openstack-infra/config のものを使用している。
  metaplugin-ci の puppet module は、metaplugin_ci のみで、これは、os-ext-testing の
  os_ext_testing module に相当するものと考えて貰えればよい。
  Jay Pipesさんは、システムによって変える部分を os-ext-testing-data に分離しているが、
  metaplugin-ci は、Metaplugin CI 専用のものなので、分離する必然性はない。そのため、
  os-ext-testing-data に相当する部分は、metaplugin-ci に中に取りこんである。

  openstack-infra/config には、様々な puppet module が定義されている。その中で、
  openstack_project module というものがある。これには、openstack インフラで使用される
  マシンの設定が入っている。以下のものを参考にしている。
  - jenkins.pp
    jenkins masterマシン用
  - zuul_dev.pp
    zuulマシン用
  - slave_common.pp
    slaveマシン用共通部分
  なぜか、一つのマシンに一つのサービスという構成になっており、jenkins master と zuul を
  同居させるような構成定義がない。metaplugin_ci の master.pp は、上記の jenkins.pp と
  zuul_dev.pp の中身を持ってきて合体させたものと(大体)考えて貰えればよい。
  metaplugin_ci の slave.pp では、slave_common.pp をそのまま利用させてもらっている。

  Ryu CI も Jay Pipes さんの os-ext-testing をベースに作られている。(metaplugin-ci の
  先輩である)
  Ryu CI では、openstack-infra/config と openstack-infra/devstack-gate にも手を入れており、
  それらをまるごと自分で取り込んだ上で修正を加えている。
  metaplugin-ci 作成時には、それら修正について、参考にさせて貰ったが、metaplugin-ci
  としては、修正せずにそのまま使用するようにした。実際、metaplugin-ciでは、修正の必要は
  なくて済んでいる(今のところ)。

・metaplugin-ci 独自定義部分
  metaplugin-ci として、独自の部分というのは、実は、以下の構成ファイルしかない、と言って
  しまっても過言ではない。
  - zuul の pipeline 定義
    /etc/zuul/layout/layout.yaml
  - jenkins の (JJBによる) job定義
    /etc/jenkins-jobs/config/ の下、特に metaplugin_ci.yaml
  以降の項で、これらの説明をする。

・layout.yaml
----------------------------------------------------------------------------------------
pipelines:            ※1
  - name: check       ※1
    failure-message: Build failed. Leave a comment with 'metaplugin-recheck' to rerun a check. ('recheck' will be ignored.) ※2
    manager: IndependentPipelineManager
    trigger:          ※3
      gerrit:
        - event: patchset-created
        - event: change-restored
        - event: comment-added
          comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*metaplugin-recheck\s*$
    success:          ※4
      gerrit:
        verified: 1
    failure:          ※4
      gerrit:
        verified: 0

projects:             ※5
  - name: openstack/neutron  ※6
    check:            ※7
      - check-tempest-dsvm-metaplugin
--------------------------------------------------------------------------------------------

  ※1 pipelineの定義。check という pipeline を定義している。
  ※2 ビルドに失敗したときのメッセージ。gerritのコメント欄に出る。
  ※3 トリガーを指定
      gerrit の以下のイベントをトリガーにする。
      - patchset が作成されたとき
      - restoreされたとき
      - 「metaplugin-recheck」というコメントが追加されたとき。
  ※4 ビルドが成功したとき、失敗したときに行うことを指定
      gerritにvote するようにしている。成功時は、+1、失敗時は、-1じゃなくて、0。
  ※5 プロジェクトの定義。
  ※6 対象プロジェクト。この定義では、openstack/neutron を指定。
  ※7 checkパイプラインで実行するjobの定義。check-tempest-dsvm-metaplugi というのは、
      jenkins のjob 定義に定義がある。

  補足:
  - commentの正規表現は、ruby の正規表現とのこと。他の例題をまねて書いたが、実際には
    精査していない。(metaplugin-recheck というコメントで、jobが実行されるのでよしと
    している。)
  - 最近、recheck で始まらないのがトレンドとのことなので、recheck-metapluginではなく、
    metaplugin-recheck としている。(recheckで始まると、Openstack infra本体のjenkins
    が拾ってしまうためらしい。)

・metaplugin_ci.yaml
------------------------------------------------------------------------------------------
- job:
    name: 'check-tempest-dsvm-metaplugin'
    description: 'Third-party testing for Neutron MetaPlugin'
    node: 'devstack_slave'                                 ※1

    wrappers:
      - timeout:
          timeout: 60  # Timeout in *minutes*
          fail: true   # A job run that exceeds the timeout will cause a failure
      - timestamps

    builders:
      - shell: |                                           ※2
          #!/bin/bash -x
          sudo rm -rf /opt/stack/logs                      ※3
          # TODO: reduce cleanup range
          sudo rm -rf /opt/stack/new                       ※4

          sudo ovs-vsctl --if-exists del-br br-int         ※5
          sudo ovs-vsctl --if-exists del-br br-ex
          sudo ovs-vsctl --if-exists del-br br-tun

          rm -rf devstack-gate                             ※6
          ln -s /opt/devstack-gate
      - shell: |
          #!/bin/bash -xe
          export LANG=C                                    ※7
          export PYTHONUNBUFFERED=true
          export DEVSTACK_GATE_TIMEOUT=180
          export DEVSTACK_GATE_NEUTRON=1                   ※8
          export DEVSTACK_GATE_TEMPEST=1                   ※8
          export ENABLED_SERVICES=metaplugin               ※9
          export DEVSTACK_GATE_FEATURE_MATRIX='/opt/metaplugin-ci/files/features.yaml'  ※10
          export DEVSTACK_GATE_TEMPEST_REGEX='tempest.api.network'                      ※11

          function pre_test_hook {                         ※12
              cp /opt/metaplugin-ci/files/neutron_thirdparty/metaplugin $BASE/new/devstack/lib/neutron_thirdparty/
          }
          export -f pre_test_hook

          cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh     ※13
          ./safe-devstack-vm-gate-wrap.sh
      - link-logs  # In macros.yaml

    publishers:
      - devstack-logs  # In macros.yaml                     ※14
      - console-log  # In macros.yaml                       ※14
      - post-tasks:                                         ※15
          - matches:                                        ※16
              - log-text: ''
                operator: AND
            script: |
              bash /opt/metaplugin-ci/files/jenkins-slave.sh offline  ※17
              sudo /sbin/shutdown -r +1 &

- project:
    name: metaplugin-ci

    jobs:
        - check-tempest-dsvm-metaplugin:
-------------------------------------------------------------------------------------------

  ※1 この「devstack_slave」というラベルがついた slave ノードが実行ノードとして選択される。
  ※2 前回jobの後始末を行っている。
  ※3 jobのログは、/opt/stack/logs/ の下に集約される。ここでは、前回のログを削除している。
      /opt/stack/logs/ は、job実行の過程で作成される。
  ※4 devstackの実行環境が、/opt/stack/new/ の下に作成される。前回実行のゴミが残っている
      ため削除している。ゴミだけ選択して消すことも考えられるが、面倒なので全部消している。
      (あまり実行時間に差がないようだ。コメントは消しておく必要がある。)
  ※5 jobの実行後は、ノードをリブートしている。ovs関連は、リブートしても消えないので、
      消している。これらは、devstackで再度作成される。
  ※6 jobで利用している、devstack-gate/devstack-vm-gate-wrap.sh スクリプト(等)を
      jenkinsのworkspace上に持ってくる(実際にはシンボリックリンクだが)。jobの都合上。
  ※7 script中で、コマンドの出力を解析しているところがある。日本語だとまずい。
  ※8 neutron および、tempest を有効化。(これらはオプションの扱いなので)
  ※9 metapluginを使用するため。
  ※10 起動サービスを絞るため。起動サービスは、feature.yaml を解析して決められている。
      devstack-gate オリジナルの feature.yaml だと、horizon 等、必要のないサービスまで
      起動されてしまうので、独自の feature.yaml を使うようにしている。
  ※11 tempestの実行範囲を指定。現状は、tempest.api.networkのみ実行。複数ある場合は、
      'aaa bbb ccc' のように列挙すればよいはず。
  ※12 metapluginを使用するための仕掛け。pre_test_hook は、devstack 実行前に実行される関数
      で、このように外で指定することが可能。
      ここでは、neutron_thirdparty 配下に metaplugin スクリプトを置いている。これと、※9
      の指定により、devstack実行時に metapluginスクリプトが実行され、それにより、metaplugin
      が使用されるようになる。
  ※13 devstack-vm-gate-wrap.sh の処理内容については、後述。
  ※14 ログ一式とコンソールログをSCPで、ログサーバに転送する。
  ※15 jobの最後に行う作業を定義。devstack-vm-gate-wrap.sh では、devstackを起動してそのまま
      なので、後始末をする必要があるが、rebootするのが一番面倒が少ないので、rebootするように
      してある。
  ※16 post-taskを実行する条件を記述。ここでは、常に実行されるよう指定。
  ※17 reboot中にjobがスケジュールされないよう、こここで、明にofflineにする。
      起動時にonlineになるようにしてある。

未稿(続く予定)

○ 注意事項、課題

・jenkins SCP プラグイン
  ログの転送に SCP プラグインを使用している。SCP プラグインの公式最新版は、1.8 であるが、
  これは、ドキュメント( http://ci.openstack.org/jenkins-job-builder/publishers.html )
  に書いてあるパラメータ、copy-after-failure、copy-console をサポートしていない。
  これらは、まだ公式リリースされていない 1.9 でサポートされている。
  これらのパラメータは、OpenStack公式のCI環境でも使用されており、開発版を使用しているもの
  と思われる。
  metaplugin-ci で使用しているものは、Ryu CI で使用しているものを貰ってきたものである。
  (modules/metaplugin_ci/files/scp.hpi)
  現状のmanifest(modules/metaplugin_ci/manifests/master.pp)では、これを
  /var/lib/jenkins/pkugins/ に配置するようにしている。SCP プラグインの 1.9 が公式リリース
  されたら、それを使用するように修正する。

・slave用 /opt/devstack-gate
  openstack-infra/devstack-gate 使用。slaveノード構築時から更新せずに使用している。
  使用しているcommit id は、31ec62bf50b20f2be17214f4a02d279a5564d300

  また、以下のローカル修正をしている。
----------------------------------------------------------------------------------------
--- a/devstack-vm-gate-wrap.sh
+++ b/devstack-vm-gate-wrap.sh
@@ -320,7 +320,7 @@ if ! function_exists "gate_hook"; then
     # the command we use to run the gate
     function gate_hook {
         remaining_time
-        timeout -s 9 ${REMAINING_TIME}m $BASE/new/devstack-gate/devstack-vm-gate.sh
+        timeout -s 9 ${REMAINING_TIME}m /opt/devstack-gate/devstack-vm-gate.sh
     }
 fi
------------------------------------------------------------------------------------------
  (注: gate_hookをjenkins jobの中で定義し直せば、ここで修正しなくてもできる。今は、
   そこまでしていない。)
  課題: openstack-infra/devstack-gate の更新への追随。
        更新ごとに対応する必要はない。ときどきは最新版をチェックする必要あり。

・zuul のコネクション問題
  zuulでは、gerritサーバにsshで入って、イベントストリームを取得している。
  (「gerrit stream-events」コマンドを実行して、その出力を読んでいる。このコマンドは、永遠に
   実行し続ける。)
  イベントストリームの入力が止まってしまい、jenkins job が実行されなくなるトラブルがたまに
  起きる。
  これは、ネットワーク経路のどこかで、コネクションが切断されているものと推察している。
  (zuulとしては、単に入力待ちしているだけで、zuulから送信することはない。入力(すなわち、
   gerrit stream-eventsの出力)がなければ、何のやりとりもされない。)
  (Ryu CI で同様の現象が発生し、そのケースでは、ルータの設定で、コネクションが切断されて
   いたとのこと。ルータの設定を変えて対処されたとのこと。)
　metaplugin-ci 環境では、ネットワーク環境の詳細が不明のため、zuul側で対処を行った。
  zuul の入力待ちにタイムアウトを設け、タイムアウトしたときに、コネクションを張り直す対処を
  入れた。
  修正については、files/zuul-timeout.patch に格納してある。masterを構築し直した場合は、
  修正を当て直す必要がある。


以上