Spencer Krum，Elizabeth K. Joseph両氏がFOSDEMの構成管理開発者セミナで，OpenStackを使用したパブリックインフラストラクチャの利用と提供についての，自らの体験を発表した。

オープンソース・インフラストラクチャの利用

HPのクラウドエンジニアであるSpencer Krum氏は，OpenStack.orgチームの開発によるPuppetベースのアップストリームインフラストラクチャを使用した，OpenStackのHPディストリビューションの提供に従事する。同社では，OpenStackに独自に作成したパッチを適用して，社内でテストした，独自のOpenStackディストリビューションを開発している。

私たちにとって，このインフラストラクチャの利用にメリットがあるのは，アーキテクチャとしての将来性を確信しているからです。アップストリームからの逸脱は，技術的な負債(Technical Debt)に他なりません。

HPの場合，アップストリームであるOpenStack.orgチームが２つのOpenStackクラウドを使用し，HPのダウンストリームでは，他の理由からネットワーク的な問題を発生していた，２つのデータセンタによる１つのOpenStackを使用している。アップストリームは相互に切り離されたコンポーネントであるため，ダウンストリームを容易に利用することができる。一方のダウンストリームでは，複製の対象を決定することが目標となる。

HPで彼らは，アップストリームの変更にコントリビューションした。コントリビューションの内容はごく小規模であるか，あるいは，特別なケースとしてダウンストリームでカスタマイズ可能な，条件付きのものとする必要があった。大規模なパッチは処理が難しい上に，アップストリームでのコミッタの作業を困難にするからだ。また，コミッタとコントリビュータの間の信頼関係を構築するという，社会的な理由もある。

彼らは，アップストリームリポジトリとダウンストリームリポジトリのPuppetバージョンの違いや，Puppet Apacheなど古いモジュールの利用，モノシリックなPuppetリポジトリなどの問題に直面しなければならなかった。そこではPuppet 2.7から3.7へのマイグレーション，データの複数gitリポジトリへの分割，モノシリックなgitリポジトリからモジュール単位のリポジトリへの分割，Puppet ForgeへのモジュールのリリースにPuppet Blacksmithを導入，提案された変更に対する統合テストの実行，といった対策が行われた。

現行のアップストリームのOpenStackリポジトリに対しては，モジュールのセマンティックバージョニングの導入や，推移的な依存問題を回避するために，モジュール依存性のフェッチにgit cloneを使用することなどが計画されている。HPのダウンストリームリポジトリでは，自身の環境のテストに関するすべてをOpenStack内で実行することや，Puppet 3へのアップデート，さらなるテストのデプロイなどを実行する予定だ。

完全にパブリックなPuppet

HPで自動化とツールを担当するエンジニアであり，OpenStack.orgではCIチームで開発を行っているElizabeth K. Joseph氏が，同社のPublic Infrastructureプロジェクトについて講演した。

氏はパブリックインフラストラクチャを持つことのメリットを，次のように説明した。

• 実例の提供
• 優れたプラクティスの促進
• 組織内部からの変更提案が可能になる
• コミュニティと共有することの素晴らしさ

企業間の競合を回避するため，OpenStackには，オープンソースのツールのみを使用するというポリシがある。自らのインフラストラクチャ設定をオープンソース公開し，パブリックビューを提供しているプロジェクトとしては，他にもDebian, Mozilla, Jenkinsなどがある。

Puppetに関して氏は，次のことを推奨している。

• 既存のモジュールを活用する，あるいは，共有を意識して新たに開発する。
• 既存のシステム設定とPuppet設定を分割する。
• 機密性のない特殊なコンフィギュレーションは，別モジュールに分割する。
• 機密データにはHieraを使用する。
• モジュールのコンフィギュレーション使用方法や，コミットあるいはバグ報告によるコントリビューションの方法についてのドキュメントを作成して，ソースにリンクしておく。
• コンフィギュレーションファイルにライセンスを付加する。再利用のためには，これが重要だ。

OpenStackでは，Puppet Dashboardのレポート機能を代替するために，PuppetDBへのWebインターフェースであるpicを使用している。これを使用することで，インフラチームに問い合わせしなくても，自身のパッチの適用状況やサーバの状態を確認することが可能になり，インフラストラクチャに対する視認性を開発者に提供する。

他のものではなくPuppetを使用する理由について，氏は次のように答えている。

私たちがPuppetを使うのは，チームの規模が小さいことと，Puppet とChefを試したメンバが最初にマスタしたのがPuppetだった，という理由からです。もしスクラッチから始めていたとすれば，至る所にエージェントを配置するような状況を回避するために，Ansibleを使用していたでしょう。