VagrantでChef Soloのバージョンを指定する方法

あらまし

VagrantでChef soloを使っているとエラーが出た。

ERROR: undefined method `sensitive' for Chef::Resource::Template

ここを見るとどうもChef soloのバージョンが古いようなのでアップデートしようとしたのでその手順をまとめてみた。

流れ

まずエラーの確認。

==> rqbbitmq1: [2014-12-26T06:11:38+00:00] INFO: Forking chef instance to converge...
==> rqbbitmq1: [2014-12-26T06:11:38+00:00] DEBUG: Forked instance now converging
==> rqbbitmq1: [2014-12-26T06:11:38+00:00] INFO: *** Chef 11.8.2 ***
==> rqbbitmq1: [2014-12-26T06:11:38+00:00] INFO: Chef-client pid: 1921
==> rqbbitmq1: [2014-12-26T06:11:38+00:00] DEBUG: Building node object for rabbitmq1

...

[2014-12-26T06:11:39+00:00] ERROR: undefined method `sensitive' for Chef::Resource::Template

sensitiveというメソッドがないというのが原因と言われるが、Chefのドキュメントには載っている。

同じエラーでぐぐってみると以下の記事が見つかった。

ChefのMySQLクックブックでNoMethodError: Undefined Method `sensitive' for Chef::Resource::Executeの対処

そこではChefのsoloのバージョンが古いので上げれば動くようになると書いてあったが、Vagrantでchef soloのバージョンを上げる方法がわからないので調べる。

Vagrantのchef soloについてのドキュメントを見るとversion指定でいける模様。

conf.vm.provision :chef_solo do |chef|
  chef.log_level      = :debug
  chef.json           = load_node_json(conf.vm.hostname)
  chef.cookbooks_path = %w(../ berks-cookbooks)
  chef.version = '11.16.4'
end

実行

VagrantPlugins::Chef::Config::ChefSolo
Bringing machine 'rqbbitmq1' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

chef solo provisioner:
* The following settings shouldn't exist: version
* The following settings shouldn't exist: version

なんかversionがないと怒られた。 ドキュメントを読み直すとinstallオプションにforceを指定しないといけない模様なので指定してみる。

conf.vm.provision :chef_solo do |chef|
  chef.log_level      = :debug
  chef.json           = load_node_json(conf.vm.hostname)
  chef.cookbooks_path = %w(../ berks-cookbooks)
  chef.install = 'force'
  chef.version = '11.16.4'
end

再度実行

Bringing machine 'rqbbitmq1' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

chef solo provisioner:
* The following settings shouldn't exist: install, version
* The following settings shouldn't exist: install, version

おかしい・・・動かない・・・ しかたがないのでソースコードを覗くためにGithubのVagrantを見に行く。

どうやらこのコミットでversionとinstallが使えるようになったらしい。

versionは1.7.0からということで自分の手元を確認。

% vagrant -v
Vagrant 1.6.5

1.7以前だったのでバージョンアップ

% vagrant -v
Vagrant 1.7.1

これで上記のchef.install='force'とchef.version='11.16.4'を指定したVagrantfileで再度実行

   rqbbitmq1: Installing Chef (11.16.4)...

無事に動いた。

結論

• Vagrantのバージョンが1.7以降であればChef Soloのバージョンを指定してインストールが出来る
• バージョンを指定したインストールをするために
• Vagrantfileのprovisionでchef_soloを指定する
• chef_soloの設定でinstall='force'とversion='任意'を指定する

参考

• ChefのMySQLクックブックでNoMethodError: Undefined Method `sensitive' for Chef::Resource::Executeの対処
• https://docs.chef.io/resource_common.html
• https://docs.vagrantup.com/v2/provisioning/chef_solo.html
• https://github.com/mitchellh/vagrant/commit/a8fa4bccc745ff9b86f130cf33576335f8f56f52

VagrantでCloudn Compute VPC (OpenNW)を操作する

背景

VagrantでCloudn Compute Flatは操作できるけど、VPC(OpenNW)が操作できないと周りで聞いたので解決できるかやってみた。

環境

最初に使った環境は以下のとおり

% vagrant -v
Vagrant 1.7.0

手順

vagrant-cloudstack pluginの導入

まず何にも用意がないのでまずはvagrant-cloudstackのプラグインを入れる。

% vagrant plugin install vagrant-cloudstack

無事に入ったことを確認

% vagrant plugin list                                                                                                                        
vagrant-cloudstack (0.10.0)
vagrant-share (1.1.3, system)

Vagrant用のテンプレートの作成 ~ Vagrantfileの作成

CloudnとVagrantを組み合わせて使う方法 を参考にさせてもらう。

が、何故か手元だとCloudmonkeyが動いてくれないので頑張って動かす。

MacでCloudmonkeyが動かなかったのでなんとかしてみた

動いたと思ったら、Cloudmonkeyの設定ファイルが変わっていたので設定の変更。

[core]
profile = server
...
[server]
apikey = your_apikey
secretkey = your_secretkey
url = https://vpcopennw-api.jp-e1.cloudn-service.com/client/api
expires = 600
timeout = 3600
verifysslcert = true

VagrantからCloudStackの操作に必要な情報をCloudmonkeyで拾ってくる。

> list templates templatefilter=self
template:
id = xxxx
name = vagrant  

> list vpcs
vpc:
name = xxx
id = xxxx

> list zones
zone:
name = jp-e1a
id = 80827400-840e-4e14-a0f3-54a998abff82

> list securitygroups
securitygroup:
id = xxxx

> list serviceofferings
serviceoffering:
name = m1.small
id = c6b72b0d-8541-474f-b617-e0051a9b6325

Vagrantfileを作成

Vagrant.configure(2) do |config|
  config.vm.box = "dummy"
  config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key"

  config.vm.provider :cloudstack do |cloudstack, override|
    cloudstack.host       = 'vpcopennw-api.jp-e1.cloudn-service.com'
    cloudstack.path       = '/client/api'
    cloudstack.port       = 443
    cloudstack.scheme     = 'https'
    cloudstack.api_key    = 'xxxxx'
    cloudstack.secret_key = 'xxxxx'

    cloudstack.template_id         = 'xxxx'
    cloudstack.service_offering_id = 'c6b72b0d-8541-474f-b617-e0051a9b6325'
    cloudstack.zone_id             = '80827400-840e-4e14-a0f3-54a998abff82'
    cloudstack.security_group_ids  = ['xxxx']

    cloudstack.name = 'cloudn-openNW-instance'

    # ネットワークの種類と名前を指定
    cloudstack.network_type = 'Advanced'
    cloudstack.network_id   = 'xxxx'

    cloudstack.instance_ready_timeout = 300
  end
end

Vagrantの実行

準備はできたのでいざゆかん！

% vagrant up --provider=cloudstack
...
==> default: Waiting for instance to become "ready"...
==> default: Waiting for SSH to become available...

SSHがつながらなくてここから進まない・・・。 しかしながらWebコンソール上では元気に動いているように見えるので原因を考える。

・・・そうかVPCだから踏み台経由しないとインターネット越しだとつながらないのか。

というわけで、さっき起動したVMにVPCの静的NATをかましてそこを踏み台に。

踏み台サーバにVagrantを導入

まずsshでアクセス

% -i ~/.vagrant.d/insecure_private_key vagrant@xxx.xxx.xxx.xx

めんどくさいのでrootに上がっておく。

% sudo su -

Vagrantを落としてくるためにwgetを導入してからVagrantを入手してインストール。 もちろんvagrant-cloudstackもインストールするのだがgccがないとvagrant-cloudstackがインストールできなくて困るのでgccも入れておく。

# yum install -y wget gcc
# wget https://dl.bintray.com/mitchellh/vagrant/vagrant_1.7.1_x86_64.rpm
# rpm -ihv vagrant_1.7.1_x86_64.rpm
# vagrant plugin install vagrant-cloudstack

これでVagrantが動く環境ができたので、あとはVagrantfileの用意をしなおす。

# mkdir cloudn-opennw
# cd cloudn-opennw
# vagrant init
# vi Vagrantfile

Vagrant.configure(2) do |config|
  config.vm.box = "dummy"
  config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key"

  config.vm.provider :cloudstack do |cloudstack, override|
    cloudstack.host       = 'vpcopennw-api.jp-e1.cloudn-service.com'
    cloudstack.path       = '/client/api'
    cloudstack.port       = 443
    cloudstack.scheme     = 'https'
    cloudstack.api_key    = 'xxxxx'
    cloudstack.secret_key = 'xxxxx'

    cloudstack.template_id         = 'xxxx'
    cloudstack.service_offering_id = 'c6b72b0d-8541-474f-b617-e0051a9b6325'
    cloudstack.zone_id             = '80827400-840e-4e14-a0f3-54a998abff82'
    cloudstack.security_group_ids  = ['xxxx']

    cloudstack.name = 'cloudn-openNW-instance01' # 名前は上記のものと違うのを指定すること

    # ネットワークの種類と名前を指定
    cloudstack.network_type = 'Advanced'
    cloudstack.network_id   = 'xxxx'

    cloudstack.instance_ready_timeout = 300
  end
end

再挑戦

# vagrant up --provider=cloudstack
...
==> default: Waiting for instance to become "ready"...
==> default: Waiting for SSH to become available...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if its present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine is booted and ready for use!
==> default: Rsyncing folder: /root/ => /vagrant

無事に起動できたので接続確認

# vagrant ssh
Thanks for using Official Template (CentOS).

====================================================
* Time Zone *
    Default TimeZone is UTC.
    You can change this with
      #sh /root/tzconfigurator.sh

* Stack (Application Set) *
    Default install apps is following.
      - ntp
      - acpiphp
      - password-agent
      - openssh-clients
      - wget
      - telnet
      - rsync

    You can update those apps to latest version with
      #yum update

    If you want to install some stack,
    you can install that with
      #sh /root/package_installer.sh

* To Change this message *
    please edit “/etc/motd”.
====================================================
[vagrant@cloudn-openNW-instance01 ~]$

無事にCloudnのOpenNW上に接続できるインスタンスをVagrantから建てられた。

結論

• VagrantからCloudnのOpenNWにインスタンスを建てることはできる。
• インターネット越しだと起動までしかできない。
• VPC内からであれば起動からアクセスまで可能
• FlatタイプとOpenNWで多少のVagrantfileの変更が必要
• OpenNWはNWタイプをAdvancedにしてNWのIDが必要
• アクセス先のURLの変更が必要

おまけ

vagrant-cloudstackのソースコードを眺めたけど、VPCを作る機能はなさそうだった。 というわけで、Vagrantを使う際は予めVPCとサブネットを作り、静的NATをしたインスタンスを用意した上でそのインスタンスからやってください。

参考

• CloudnとVagrantを組み合わせて使う方法
• vagrant-cloudstack

Ansible Configuration Fileのtransport=smartについて

今年の夏ぐらいからChefあらAnsibleに乗り換えてまあまあ使ってきました。 Chefと比較した場合のAnsibleの利点として、エージェントレスで動作するということが挙げられます。

このエージェントレスでの動作ですが、簡単に言うと毎回SSH（他のプロトコルも利用可能）でアクセスして接続先のホストでコマンドを発行して任意の操作を実行しているわけです。

しかし、タスクごとに毎回SSHのセッションを張るのでタスクが多くなってくると意外と遅い。

そこで設定transport=smartの出番です。というかこれデフォルトだとsmartらしい。

まずSSHのControlPersistについて軽く説明。 ControlePersistはOpenSSHの5.6から搭載された機能で、SSHの多重化接続の永続化をしてくれる機能らしい。 つまり、ControlPersistで指定した場合、永続化されたセッションを使うのでアクセスが早くなるという仕組みになっている。 また、ControlPersistはタムアウト設定を指定することも可能なので1mとすると1分間アクセスがない場合は自動的にセッションが切れる。

で、話をtransport=smartに戻す。 transport=smartはSSHのControlPersistが利用可能（OpenSSH 5.6以降）な場合はOpenSSHを利用し、ControlPersistが使えない場合はPythonのSSHライブラリであるparamikoを使うという設定らしい。

まぁ、実を言うとOpenSSH 5.6以降がデフォルトで入ってるのはEnterprise Linux 6というかRHELの6とかCentOSの6なんでそれ以外だとControlPersistが有効になっているはず。 それでも遅いなと思う人や1分以上処理に時間が掛かる（パッケージインストール等）をする人は、設定ファイルのssh_argsで以下のように設定すると幸せになれるかも。

ssh_args = -o ControlMaster=auto -o ControlPersist=30m

公式的には30分がおすすめらしい。

結論

• 設定ファイルにtransport=smartを明示しなくてもデフォルトでsmartが適用されている
• OpenSSH 5.6以上を使うとAnsibleのタスクが早くなる
• Enterprise Linux 6(RHEL6, CentOS6)はデフォルトだとOpenSSH 5.6以下なので自力で何とかする
• 処理に時間が掛かるタスクがある場合はssh_argsでControlPersist=30mを設定しておく

参考

• SSHの多重接続について | Siguniang's Blog
• The Ansible Configuration File — Ansible Documentation

MacでCloudmonkeyが動かなかったのでなんとかしてみた

cloudmonkeyで遊んでみようとしたら、エラーが出て動かなかったのでなんとかしてみた。

まずはcloudmonkeyのインストール

% sudo pip install cloudmonkey

そして実行するとエラーはこんな感じにでてくる。

% cloudmonkey
Traceback (most recent call last):
  File "/usr/local/bin/cloudmonkey", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2603, in <module>
    working_set.require(__requires__)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 666, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 565, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: requests

なんかrequestsのパッケージが見つからない的なことを言っているのでいれてみる。

% sudo pip install requests
Requirement already satisfied (use --upgrade to upgrade): requests in /Library/Python/2.7/site-packages
Cleaning up...

すでに入っている。。。

とりあえずググるとこんなのが出てくる。

pip - DistributionNotFoundエラーの対処方法 - Qiita

pipをアップグレードしてみる。

% sudo easy_install --upgrade pip

これでも動かない。

さらにぐぐる。

python - No module named pkg_resources - Stack Overflow

これで動いた。

% pip install --upgrade setuptools
% pip install --upgrade distribute
% cloudmonkey
Selected profile (local) does not exist, using defaults
Missing configuration was set using default values for keys:
`profile = local, asyncblock = true, paramcompletion = true, history_file = /Users/Mahito/.cloudmonkey/history, cache_file = /Users/Mahito/.cloudmonkey/cache, log_file = /Users/Mahito/.cloudmonkey/log, color = true, prompt = 🐵 > , display = default` in /Users/Mahito/.cloudmonkey/config
☁ Apache CloudStack 🐵 cloudmonkey 5.3.0. Type help or ? to list commands.

Using management server profile: local

(local) 🐵 >

どうも入ってたrequestsかdistributeのバージョンが古かったのかなという気がする。

何はともあれ動いてよかった。

SECCON 2014 オンライン予選（英語）32時間 CTFに参加してました

12/6-7に行われていた32時間耐久SECCON 2014オンライン予選（英語）にctpmのメンバとして参加してました。

といいながら、子供の相手した李家の掃除とかしてからの参加だったので、1日目11時間ぐらいと2日目5時間ぐらいの計16時間ぐらいの参加でした。（上：瞬間最大風速、下：最終結果）

瞬間最大風速では全体3位、国内1位だったものの後半伸び悩んでズルズルとさがり、結果として全体25位(全802チーム中)、国内6位でした。 他のチームメンバに頑張ってもらいましたが、QRコード職人としての面目躍如の2問解いたのでwriteup書いておきます。

QR (Easy)

• 問題文

  世界一面白いジョーク： 昨晩フランネルケーキを食べる夢を見たんだけど、 朝起きたらQRコードが半分なくなってたんだ！

というわけで、去年のオンライン予選よろしく半分になったQRコードの画像があるので復元開始。

このへんとか

Format and Version Information - QR Code Tutorial

このへんをみてフォーマットとタイミングパターンを補ってあげる。

Format and Version String Tables - QR Code Tutorial

分かるのはECC LevelがHでマスクパターンが(row) mod 2 == 0。 で、残ってるデータはどこまであるのかを確認してみると、データ部分はまるっと残っているらしい。

ならこれ以上復元しなくても問題ないやと、あとはWindowsの人に投げてQRコードを読み込んでもらっておしまい。

※最初復元して読み込んだのに通らなかったけど黒塗りの漏れがあったので修正したら通った。

BBQR

• 問題文

  Let's enjoy BBQR!

というわけで、今度こそ去年と同じ焼けたQRコード。 多分このサイトの最後の一文原因じゃないかなと思ったり。。。

SECCON CTF 2013 online予選 forensics 400 : Eleclog.

今度はQRコードの右半分が消えているので、つまりデータ領域がないので単純に復元はできない。

今回もECC LevelはHだが、マスクパターンは(row + column) mod 2 == 0

一応復元したQRコードにレイヤを重ねてみると幸いにパリティ部分はまるっと残っているのでそちらから復元しろということなのかなと思う。

調べるとリード・ソロモン符号の複合とかになってちんぷんかんぷん。

リード・ソロモン符号 - Wikipedia

いろいろ考えてもできそうになし時間もないのでどうしようかなと考えた結果、Keyは英数字で文字数はQR(Easy)だと勝手に決めつけて、そちらからデータを引っ張ってくれば複合できるのではないかと思い試してみる。

ただ、単純にコピペだとダメそうな気がしたのでQR(Easy)のマスク(row) mod 2 == 0を外したものを、今回のQRコードのマスクである(row + column) mod 2 == 0に再度マスキングしておく。

これをWindowsの人に読み込んでもらったらKeyが出て無事にSubmit。

というわけで、今度こそQRコードは煮たり焼いたり食べたりしないでくださいね！

結局、無事にQR担当のお役目は務めたもののそれ以外はHeartbleed問題用の環境をCloudnの上に構築した程度。 あんまり役に立てなかったのでチームの弱い部分を埋めるスキルを身につけるかな・・・

DevStackでSahara（Juno版）を動かしてみよう

こんばんは。 現在12月8日の33時です。 今日の記事は「OpenStack (２枚目） Advent Calendar 2014」12/8 分です

OpenStackのJuno版から入ったデータ処理サービス「Sahara」に興味があったので、DevStackでSaharaを動かすまでの軌跡を書いております。

Setup DevStack — Sahara

ドキュメントを見ると、DevStackのlocal.confに以下の行を追加するだけで動きそうです。

# Enable Sahara
enable_service sahara

あとはstack.shを叩くだけ！

%  ./stack.sh

何だ簡単じゃん！

そんなわけなかった。。。

1. Horizonのテストでコケる

VagrantでUbuntuのBoxを拾ってきて構築したものの、gettextパッケージがないと言ってテストがコケる。

2014-11-28 02:13:29.288 | HEAD is now at d9f336b Merge "Make status in instance details screen translatable" into stable/juno
2014-11-28 02:13:29.290 | + cd /opt/stack/horizon
2014-11-28 02:13:29.290 | + ./run_tests.sh -N --compilemessages
2014-11-28 02:13:29.613 | WARNING:root:No local_settings file found.
2014-11-28 02:13:29.744 | CommandError: Can't find msgfmt. Make sure you have GNU gettext tools 0.15 or newer installed.
2014-11-28 02:13:29.780 | + exit_trap
2014-11-28 02:13:29.780 | + local r=1
2014-11-28 02:13:29.781 | ++ jobs -p
2014-11-28 02:13:29.781 | + jobs=
2014-11-28 02:13:29.782 | + [[ -n '' ]]
2014-11-28 02:13:29.782 | + kill_spinner
2014-11-28 02:13:29.782 | + '[' '!' -z '' ']'
2014-11-28 02:13:29.782 | + [[ 1 -ne 0 ]]
2014-11-28 02:13:29.782 | + echo 'Error on exit'
2014-11-28 02:13:29.783 | Error on exit
2014-11-28 02:13:29.783 | + [[ -z /opt/stack/logs ]]
2014-11-28 02:13:29.783 | + /home/vagrant/devstack/tools/worlddump.py -d /opt/stack/logs
2014-11-28 02:13:29.819 | + exit 1

horizon/install.rst at master · openstack/horizon · GitHub

Installの手順を見ると思いっきりgettextが必要なんですが、DevStackのHorizonが必要とするパッケージには書かれていない。

devstack/horizon at stable/juno · openstack-dev/devstack · GitHub

よってfiles/apts/horizonにgettextを追加。

apache2  # NOPRIME
gettext # 追加
libapache2-mod-wsgi  # NOPRIME
python-beautifulsoup
python-dateutil

2. requirementsが最新じゃない

インストールの最中にライブラリが足りないみたいなエラーで落ちる。

2014-12-09 00:49:51.052 | Syncing /opt/stack/sahara/requirements.txt
2014-12-09 00:49:51.052 | 'oslo.middleware' is not in global-requirements.txt
2014-12-09 00:49:51.072 | + exit_trap
2014-12-09 00:49:51.072 | + local r=1
2014-12-09 00:49:51.073 | ++ jobs -p
2014-12-09 00:49:51.074 | + jobs=
2014-12-09 00:49:51.074 | + [[ -n '' ]]
2014-12-09 00:49:51.074 | + kill_spinner
2014-12-09 00:49:51.074 | + '[' '!' -z '' ']'
2014-12-09 00:49:51.074 | + [[ 1 -ne 0 ]]
2014-12-09 00:49:51.074 | + echo 'Error on exit'
2014-12-09 00:49:51.075 | Error on exit
2014-12-09 00:49:51.075 | + [[ -z /opt/stack/logs ]]
2014-12-09 00:49:51.076 | + /home/vagrant/devstack/tools/worlddump.py -d /opt/stack/logs
2014-12-09 00:49:51.117 | + exit 1

よく見るとstable/juno版にはないライブラリが必要らしく、requirementsの最新版に入ってることを確認。 local.confに以下の行を追加。

REQUIREMENTS_BRANCH=${REQUIREMENTS_BRANCH:-master}

3. Internal Server Error

これでようやくHorizonのダッシュボードからSaharaの画面が見えた。 ということでSahara触ってみようとすると500 Internal Server Errorをもらう。 ログを見ると以下のとおり。

2014-11-26 08:10:22.602 ERROR sahara.utils.api [-] Request aborted with status code 500 and message 'Internal Server Error'
2014-11-26 08:10:22.602 ERROR sahara.utils.api [-] Traceback (most recent call last):
  File "/opt/stack/sahara/sahara/utils/api.py", line 89, in handler
    return func(**kwargs)
  File "/opt/stack/sahara/sahara/api/acl.py", line 46, in handler
    exc=exceptions.Forbidden)
  File "/opt/stack/sahara/sahara/openstack/common/policy.py", line 314, in enforce
    self.load_rules()
  File "/opt/stack/sahara/sahara/openstack/common/policy.py", line 241, in load_rules
    self.policy_path = self._get_policy_path(self.policy_file)
  File "/opt/stack/sahara/sahara/openstack/common/policy.py", line 287, in _get_policy_path
    raise cfg.ConfigFilesNotFoundError((path,))
ConfigFilesNotFoundError: Failed to read some config files: policy.json

policyを見に行こうとするのだが、policyがないというのでいろいろ考えるものの動かない。 いろいろ調べた結果、これstable/junoじゃないのでは・・・

というわけで、devstackのstable/junoブランチのstackrcを見に行くと。

devstack/stackrc at stable/juno · openstack-dev/devstack · GitHub

# compute service
NOVA_REPO=${NOVA_REPO:-${GIT_BASE}/openstack/nova.git}
NOVA_BRANCH=${NOVA_BRANCH:-stable/juno}

# data processing service
SAHARA_REPO=${SAHARA_REPO:-${GIT_BASE}/openstack/sahara.git}
SAHARA_BRANCH=${SAHARA_BRANCH:-master}

# object storage service
SWIFT_REPO=${SWIFT_REPO:-${GIT_BASE}/openstack/swift.git}
SWIFT_BRANCH=${SWIFT_BRANCH:-stable/juno}

なんでmaster見に行ってんの・・・ねえ・・・ stable/junoって言ったじゃないの・・・

というわけで、Saharaのブランチをlocal.confでstable/junoに切り替え。 ついでにさっきmasterにしたrequirementsの設定は削除

SAHARA_BRANCH=${SAHARA_BRANCH:-stable/juno}

これで無事にSaharaが動いてInternal Server Errorをもらうこともなくなりました。

結論

• 2014/12/08 33時段階でのDevStack(stable/juno)のHorizonは動かない環境がある。
• gettextがない場合は入れる。
• 2014/12/08 35時段階でのDevStack(stable/juno)のSaharaはデフォルトでは動かない。
• DevStackでstable/juno版のSaharaを動かすときはlocal.confにSaharaのブランチにstable/junoを指定する
• local.confは以下のとおり

# Enable Sahara
SAHARA_BRANCH=${SAHARA_BRANCH:-stable/juno}
enable_service sahara

おまけ

gettextがない件と、DevStackのstable/juno版のSaharaがstable/junoを使っていない件をプルリクエストにして投げたら速攻クローズされた。 理由はgerrit使えだそうです。 これからgerritの設定して再度修正投げます。。。

jujuでmachineの削除ができなくて

諸事情でMAAS/jujuの素振りをしていて色々言いたくなったので書き込み。

MAASは結構いいかなと思うもののjujuとjuju-guiがかなりの困りもの。

VirtualBox上で素振りしているこっちが悪いのかもしれないが、ちょっとうまく行かなかったのでVMを消して最初からためそうとおもったところ、jujuに登録されているmachineが消えない。

コマンドを確認してもdestroy-machineの文字があるが消えない。 --forceオプションを使っても消えない。

消えないからまた最初から試そうと思ったらVMレベルで作り直しが求められる。

そしてjuju-guiを使うとなんの手違いなのか存在していないmachineを勝手に作られ、また消えない。

結果、juju statをするとゴミ情報が残って見難い。

なにか方法はないのかと思ってぐぐってみたらこんなのが

juju - How do I clean up machines in a dying state? - Ask Ubuntu

環境ごと消すしかないんか！

というわけで、jujuとjuju-guiがイケてない・・・