Apache CloudStack's Plugin Model:Balancing the Cathedral with a Bazaar (ノートには日本語です)

Editor's Notes

• #2: タイトルがよく分からない場合は…Eric S. Raymond のソフトウェア工学に関する本を参照して下さい。
• #3: -仕事とプライベートについて簡単に:写真は私のものです。質問したいのですが…家を仕事場にしている人はどのくらいいますか？オフィスに通勤している人は？家族の写真を持っていますか？写真に戻って…… ということで、夢を実現した生活をしているのが僕です。こう見えても、ケンブリッジ大学で、アスペクト指向プログラミングに関する研究でコンピュター・サイエンスの博士号と、それから法律学の学士も持っています。
• #4: * 一連のスクリーンショットで置き換えてもよい。---では、始めましょう。最初に質問です。First question, is what do I need to know to understand this presentation. That is the context for the point the that I’m going to bring up, and the context is established by the call for submissions.講演のテーマを引用…本講演のテーマをみてみましょう。企業というのはソフトウェアを長期間に渡って使いたいものである、というのが私の考えです。そのためには次の2点が重要です。まずは、ソフトウェア自体が即座に変更可能であること。オープンソースについて言えば、ソフトウェアのオーナーの責任が軽く、開発プロセスが透明で、誰でも開発に参加できます。本スライドにタイトルにあるように、まさにバザール・モデルです。一方で私たちは、自分の加える変更が秩序だっていてほしいものです。もし加えた変更を残りのシステム全体から区別するようなインターフェースがあれば、たとえ下位のシステムが変わったとしても、その変更部分を正しく動かし続けるのが容易になります。また、私たちは変更を加えた際に前提とした仕組みが変わらないでいてほしいものです。これには限界があります。それには、利用できるインターフェースにのみ固執し、それを踏み越えないように縛りを加えることが必要ですが、秩序と規律へのこの欲求は、本講演のタイトルで言えば、伽藍について語る際に当てはまるものです。分かったこと: 企業品質のソフトウェアには秩序だった適用方法が必要である。Fork するやり方では十分ではなく、また、加えた変更を容易に発展できないようでも優れているとはいえない。そして、これこそが CloudStackのプラグイン・モデルが解決している問題なのです。次に、話題をこの方向に変えましょう。この方向というのは、どのようにして、です…今日の IaaSクラウドは異機種環境のデータセンターが非常に受け入れられている、というのが私の立場です。IaaSに対する本来の究極目標は、「電力、ネットワーク帯域、運用、ソフトウェア、ハードウェアのコストをそれぞれ独立に削減する」ことです。[2] しかし、アプリケーションをハード障害への耐性をつけるには書き換えが必要です。典型的なクラウドOSであるAmazon Web Servicesは、使用している安価なマシンの障害を前提として、ダウンすることが折込済みの仮想マシンを提供しています。よって、旧来のIaaSでは、ハードとソフトはその IaaSが想定するモデルに則って利用しなければならず、これの回避策はありません。これとは反対に、企業では既存のシステム稼働に見合ったクラウドの形態を望んでいます。すなわち、柔軟かつ、計測可能であり、待機リソースが用意されている状況です。しかしながら、この既存のシステム稼働を、コモディティ・ハードで用意するという純粋な IaaSの考えに沿って実現するのは困難です。仮想デスクトップについて考えてみましょう。ユーザーは既存のライセンスに見合ったハードウェアを専有し、特別なストレージを必要とするような高品質のデータ・サービスを求めています。誰も自分のデスクトップ・マシンを手放したいとは思いません。ここで分かったことは、今日のクラウドと呼ばれるものはそれなりの性質を備えているが、既存のハードやシステムの利用形態と共存できるものではない。これがCloudStackのプラグイン・モデルが解決する問題の更なる詳細です。これによって、多種多様なデバイスをサポートすることができます。最後に、ApacheConこのカンファレンスで望んでいたのは…Focus を引用というわけで、ケーススタディを使ってプラグイン・モデルを説明していきます。そのケーススタディというのは、CloudStackにHyper-Vサポートを追加する際の問題です。「CloudStackには同一ゾーンでXen, VMWare, KVM, OVMといった複数のハイパーバイザーをサポートできるという強力な優位性があります。Hyper-Vが自身をVMWareの公認のライバルと表明している以上、私たちとしてもそれをサポートのリストに加えていく必要があります。ですので、Hyper-Vのサポートというのは、例としては興味ある格好の題材です。今から説明する経験内容は本当に真実味があるといえます。なぜなら、私はCloudStackに対しては完全に新参者だったからです。既存の開発者が持っているような知識は全くありませんでした。さらに、作業はリモートで行いました。私はタイムゾーンも地域もCitirxの同僚から遥か離れているのです。また、オリジナルのCloudStack開発メンバーでもありませんでした。私はおそらく新参者が遭遇しうるあらゆる障害物を行き当たってきたといえるでしょう。それでもなお、プラグインの PoCを実施できたのです。ここで分かったことは、私が示した点は、CloudStackの新規プラグインを作るという実体験に基づいているということです。9 分
• #5: これはCloudStackの典型的なアーキテクチャ図です。これが意味しているのは…システムを変更し始めるには、開発者にとって非常に多くのコードと知識が要求されるということです。図で見えるのとは対照的に、システムの各ブロックは分離されていません。コードを見ると、異なるシステム間が相互に依存しあっていることが分かります。システムの構成要素間を分割するような厳格なコントラクトはありません。システム全体を構築することなく、変更部分を試験するのは難しいです。このため大変時間がかかりますし、テスト駆動開発を実施するもの困難です。最後に開発者は、RESTful APIの設計や使用法からストレージ種別やネットワーク構成といったシステムレベルの注意事項といった、様々なプログラム領域を理解することが必要です。ここで分かったことは、開発に取り掛かる前に学習に多くの時間を割くことになる、ということです。全体のアーキテクチャからは、どこから機能の追加を始めたらよいか、はっきりとは分かりません。ここで分かることは、CloudStackに対して包括的にアプローチしようとすると、いいスタートダッシュを切ることは難しいということです。
• #6: CloudStackを一度に全て学習するのは…… めちゃくちゃ厳しいです。
• #7: 次に取り上げるのは、分割について、つまりCloudStackをいくつかのピースにばらして、ハードの管理をhard started with hardware management.CloudStackは1つのAPIコールの中で、データセンターのリソースの制御をいくつかのステップに分割します。プロビジョニングにより検知されるハードウェア管理プロビジョニングによってCloudStack APIコールの特定のステップは一連のハードウェアの操作となります。この部分のステップだけを取り出したものが、オーケストレーションと呼ばれます。CloudStackのオーケストレーションはデータセンターをVM、ボリューム、テンプレート、NIC、ネットワークといった観点で扱うことができ、それらの基盤技術が何であるかについてあまり考える必要はありません。DeployVirtualMachineAPI を例に取ってみましょう。これはクラウド内にVMを生成するものです。使用する管理モジュールを列挙するステップ。Network managerがネットワーク設定を受け持ち、template manager がテンプレートをハイパーバイザーに展開し、storage managerがVMのrootボリュームのローカルコピーを作成します。 VM managerはVMを構成し、テンプレートをrootデバイスとしてアタッチします。適切なネットワークにNICを割り当てる役目もあります。処理と管理モジュールの順番がちょっと違っていますが、要点は分かったと思います。こうしたステップがオーケストレーションを構成するのです。その一方、あるハードウェアへの具体的な処理は、関連するプロビジョニング・プラグインによって実装されています。実際にデータセンターを更新しているのはプロビジョニング・プラグインです。分かったこと: データセンターの制御はプロビジョニングであり、これはオーケストレーションAPIとは独立しています。[Split into separate slide]こうした分割の仕組みにより、CloudStackではシステム起動時にいくつでもプロビジョニング実装を呼び出すことができます。プラグインは実現する機能に相当するアダプターを実装します。アダプターはデータセンターの性質やデバイスに応じたカテゴリに分かれて存在します。このスライドで挙げているのはその中の数個のアダプターに過ぎません。ネットワークとハイパーバイザーのアダプターです。図の通り、HypervisorGuruアダプターではKVMやVMWare, Xen, OVMのプラグインを実装しています。分かったこと: 一連のアダプター内に新しい技術を活かす仕組みを組み込んでいます。プラグイン・モデルによりソフトウェアは今ある制約を乗り越えて発展していくことができます。新たなアダプターとして、T新ストレージ・モデルがありますが、これもプラグイン・モデルを踏襲しています。
• #8: プラグインには、サービス提供先に応じて、2つの主要コンポーネントに分かれています：CloudStack管理サーバーとデータセンター内のリソースです。管理サーバー側のコンポーネントは、管理サーバーの要求に応答し、また管理サーバーにサービスを依頼します。管理サーバーによってロードされるため、プラグインはJavaで記述されます。オーケストレーション・エンジンによって使用されるため、プラグインは必要な数のアダプターインタフェースを実装します。オーケストレーション・エンジンがストレージとハイパーバイザーを制御するなら、その2セットのアダプターを追加することになります。「セット」という言葉を使ったことに注意して下さい。これについては後に触れましょう。管理サーバー内で動作するため、下位のデータベースにアクセス可能です。DAO (Data Access Objects) によってデータベースからオブジェクトをロードしたり、更新したり、永続的なオブジェクトを生成することも可能です。例えば、ハイパーバイザーが最初に管理サーバーに接続する時、ハイパーバイザー・プラグインはhost ID等の自身の詳細情報を更新するかもしれません。プラグインはRESTfulなAPIを公開して、オーケストレーションをバイパスすることも可能です。今日はその話題に触れませんが、APIの公開は本質としては管理のための「フック」です。分かったこと：プラグインの片側半分は管理サーバー内で動作します。ServerResourceと呼ばれるリソースは、制御しようとしているデータセンター・リソースに合わせて実装されます。制御先デバイス上でエージェントとして実行することができます。KVM はLibvirtライブラリで制御されますが、これはリモートから起動をかけることができません。ですので、KVM ハイパーバイザーのServerResourceはエージェントとしてハイパーバイザー上で動作します。サーバー側のコンポーネントにもServerResourceはあるのですが、これは実際には単なるプロキシーです。コマンドはJSON でシリアライズされてTCP / IP でプロキシーからエージェントに転送されます。リモートアクセスが可能なら、ServerResourceから直接接続が可能です。XenServerプラグインがよい例です。これはリモートアクセス API　を使用します。結果として、ServerResourcesはCloudStackデータベースに直接アクセスすべきではありません。分かったこと：ServerResourceはどこででも動作できるし、様々な言語で実装可能です。というわけで、われわれのプラグインは管理サーバーとデータセンター内のリソースをつなぐ架け橋となるものです。
• #9: 以上はあくまで理論の上のことで、机上で動作を説明しただけです。実際にモデルを動作させるのに必要な諸々を知るために、Hyper-Vをサポートするプラグインを作成して行きましょう。
• #10: 私たちは新たな機能を実装するプロセスがあったことに後で気が付きました。既にご存知だったApache メンバーにはお詫びします。プロセスはあなたがコミッターではなかった場合、加えた変更をマスターブランチに取り込むときに実行します。その場合、あなたはApacheのソースコード・リポジトリへの書き込み権限は持っていないことになります。いったんマスターに取り込まれたら、大きな実装し直しがあったとしても、あなたの変更がサポート廃止になることはまずないでしょう。例えば、プラグイン・ローダーが独自実装から最近Springベースのメカニズムに変更されました。その更新内容はマスターブランチのあらゆる箇所に波及しましたが、マスターに取り込まれていないプラグインはそれを手作業で更新しなければなりませんでした。これは私にとって大いに学んだ経験でしたが、こういうことはできれば避けたいですよね。前のコンテキストについてのスライドを思い出して下さい。同プロセスはあなたが登録する必要のあるサイトについて全て記載しています。CloudStackは各作業でApache に準拠したツールを使用しています。OpenStackのLaunchPadと違い、開発サイクルの全てをカバーする統一されたGUIはありません。ソースコード管理にはGitを、バグ管理にはJIRA、変更申請には Review Boardを使います。なので、われわれもそれらのツールを使用してきました。ここに必要リンクは全て挙がっています。分かったこと、プラグインを書くのには規律正しいプロセスに則ります。しかし、Wikiについてはあなたが使いたいものを選べます。2種類のWikiが利用可能です。新規ユーザーに特化した Incubator wikiエディターを使用することで、シンプルで分かりやすいデザインです。このエディターがコンテンツを一貫性があり、理路整然としてものにしてくれます。手始めにはこれがいいでしょう。もう一つは開発者専用たくさんの質問への回答を載せることができます。例えば、Windows 環境での開発環境のセットアップ方法など。ただし、メーリングリストで指摘されるような、古くなってしまったページもできてしまいます。例えば、Mavenでのビルド移行した後も、ANTについて書かれたページが追随するにはしばらく時間がかかりました。とはいえ、このWikiは何か問題がある時には一番欲しい回答が見つかるでしょう。例えば、Windows環境の設定方法は問題があるたび常に更新されています。しかし、レイアウトはグループごとの分類しかなく、一貫性がありません。Apache プロジェクト以前のwikiは使わないこと。こうしたページが、特に開発者Wikiであまり参照されない部分で特に、Googleで毎度検索されてしまいます。ページのトップに廃止予定の注意書きがあるので、それに従って下さい。分かったこと、ひとまずincubator wikiを使ってみましょう。しかし、慣れてきたらすぐに開発者Wikiに移行しましょう。目標をまとめると、Apacheのプロセスに従い、さらにWikiの詳細なガイドを参照して、あなたのプラグインをマスターに取り込みましょう。
• #11: 理想のデザインを探求するところから始めるかわりに、既知の内容から理想に向けて進化させていきましょう。私たちの目指す理想は2フェーズで構成されます。ServerResourceの実装には WS-Management を使用するのが適しています。なぜならHyper-V上のエージェントを開発しないで済むからです。WS-Management はリモート実行用に Windows WMI インターフェースを公開します。WMI は Hyper-V API を公開しています。Windowsユーザーでない人たちのために説明すると、WMIはWindowsサブシステムが情報を共有し制御APIを登録するためのフレームワークです。私はサードパーティ製のサービス、いわゆるデーモンも、WMI経由でそのコントロールを公開することが可能であると思います。WMIのリモート実行メカニズムはDCOM スタックを使います。これはどちらかと言うとMicrosoft固有でJavaではあまりサポートされていません。WS-Management を使えば標準仕様に則ることができ、Javaでのサポートでもいくつかの選択肢を利用できます。XenServerをご存知ならXAPIに似ていると言えるでしょう。エージェントがないので、それをどう展開するかを考える必要もありません。2フェーズ・アプローチの2番めの考慮事項は、Hyper-V ベースのSystemVMです。これらのVMはCloudStackの一部を構成するもので、管理サーバーが必要とするサービスを提供します。一つはSecondary storageでテンプレートなどを保存し、もうひとつはゲスト・コンソールへのアクセス、また別にもう一つ、Isolated ネットワークでNAT変換などを提供するネットワークサービスがあります。最後の要素は、Hyper-V イメージとVM タイプのサポートをCloudStackのコアに追加することです。キャパシティ管理とVMの配置のためオーケストレーション・エンジンは、実装するわけではないのですが、Hyper-V のイメージとゲストの種別について予め知っておく必要があることが分かったのです。分かったこと、理想的な設計をしておくことで、プラグインの展開を簡単にして、Hyper-V で全てのクラウドを構築することができます。フェーズ2によって、CloudStackの学習より大きな作業が待っています。WS-Managementを使ったHyper-Vの制御のしかたについての詳細な例がありません。WMI または PowerShellで書かれた例はあります。というわけで、WMI と WS-Managementについて学ぶ必要があります。標準のJavaからWS-Managementを呼び出すのは簡単ではありません。HTTP によるWS-Management エンドポイントの呼び出しは、私たちの作業には少し低レベル過ぎます。かわりに、いくつかのサードパーティ製ライブラリでWS-Managementにアクセスするのが推奨ですが、それぞれのライブラリーには制約があります。SystemVMを作るには一連のツールがあります。もしあなたが自分でLinuxを用意するのに慣れていなければ、こうしたことを理解するには少し時間がかかります。もしよく知っていたとしても、CentOS標準のやり方から、サービスを追加したり、デーモンのインストールを変更したりする必要があります。フェーズ2で複雑な大部分はCloudStackには関係しないものです。フェーズ1ではServerResourceの書き方を学習するのに専念します。マシン上で動作するエージェントはHyper-Vを制御するために使用されます。エージェントは WMI を直接呼び出すこともできますし、同じ事をPowerShellで行うこともできます。通信はCloudStackのメッセージバスのメカニズムを使います。これは TCP/IP と JSONを使うため、やり取りされるコマンドの内容を確認するのは比較的容易です。また、既存のラッパーがあるので詳細を理解する必要はありませんし、既存のプラグインにメッセージバスの使い方の例がいくつもあります。メッセージバスは、ServerResourceとCloudStack管理サーバー内のプラグインとの間で、設定や処理実行のコマンドに関わる動作をひとまとめにしたものです。メッセージバスは管理サーバーで接続を確立するためのプロトコル、確立されたTCP接続の管理、そして規定の要求／応答オブジェクトを転送するためのネットワーク・。フォーマットを含んでいます。既存のSystemVMsを使用します。なぜならXenServerを使用するからです。XenServerでは既存のテンプレートからSystemVMを動作できます。フェーズ1はCloudStackを学習するのに適しています。分かったこと、フェーズ1では新規のアイデアを導入しないことで、CloudStackの内部動作の理解に集中することができます。
• #12: 自分でコードを書く前に、コードを再利用するため、CloudStackの内部を辿ってみましょう。既存のコードから作る私たちのリモートエージェントについて説明しましょう。上のピラミッドでは、緑の部分が既存コードで設定のみ必要なものです。青い部分が再利用して改変する部分です。新しい内容は多くはありません。リモートエージェントはKVMハイパーバイザー・プラグインから借用します。このコンテナーのスタックは、ServerResourceオブジェクトをいくつでも乗せることができます。AgentShellはデーモンプロセスに相当します。内部でバージョン処理とOS依存部分を扱います。Javaで書かれていてプラットフォーム非依存です。コンフィグファイルにもとづいて、必要なServerResourceインスタンスごとにAgentオブジェクトを立ち上げます。Agent オブジェクトはメッセージバスを管理します。接続を確立することでTCP接続のコードを書く必要はありません。さらに重要なのは、管理サーバーとの接続が確立される際のハンドシェイクの面倒もみてくれるということです。ServerResourceは KVM プラグインをベースにダミーのテストリソースを含みます。既存のハイパーバイザー制御用のServerResourceはあなたが受信するのを期待しているコマンドを示します。Agentがメッセージバス上で受信する全てのコマンドは同じサブタイプを持ちます。Agent はタイプに関係なくメッセージをServerResource内の同じメソッドに渡します。それからServerResourceメッセージを実装メソッドにディスパッチします。このディスパッチャーは、ハイパーバイザー用ServerResourceが実装することになっている一連のコマンドを振り分ける、長いif文のかたまりです。分かったこと、ServerResourceには私たちが簡単に修正できるリファレンス実装がある。Hyper-V に特化したコードは、OpenStackドライバに基づいた前述のドライバーを利用できます。Citrixが cloud.com を買収したことで、クラウドでのプロビジョニング・モデルに適したHyper-V ドライバーを書いたのです。このコードはボリューム、NICを持つVM生成のよいコード例となります。コードはPythonで書かれていて、独立したプロセスとしてJavaによって実行されます。私たちはPythonプロセスにコマンドを渡せばよいだけです。やってみて分かりましたが、これはとても簡単です。というのはCloudStackコマンドはJSONでシリアライズされているからです。それがそのままメッセージバス上を流れます。JSON はPythonのシリアライゼーション・エンジンに非常によく似ています。分かったこと、私たちはHyper-Vを制御するのに、ApacheライセンスのHyper-Vコードを使用することができました。CloudStackに既にあるものを理解するのに少し時間を使えるなら、あなたもちゃんと動く実装を作ることができますよ。
• #13: テスト駆動開発のため、ロギングされるコマンドを使いましょう。コマンドがどんなフォーマットで、どんな順序でプラグインのServerResourceに渡されるかは明確ではありません。実装するコマンドはHypervisorResourceのようなインタフェースによって示されます。しかし、インターフェースは全てに適用されるわけではありません。あなたが実装しようとするプラグインによっては、こうしたインターフェースがまったく実装されていないかもしれません。インターフェースは完璧ではありません。例えば、HypervisorResourceを適切に操作すれば、システムがサポートするVM、ホスト、ストレージの状態を取得するメッセージを返すはずです。私がコンポーネント分割は現在も進行中であると言ったことを思い出して下さい。これはプラグインが実装必須なものを統一するコントラクトもまた作業進行中であることを意味します。コマンド自体はたくさんのフィールドがあり、その値の意味はいつも明確ではありません。わかったこと、あなたのプラグインがどのメッセージを受信するか推測してはいけません。そうではなく、既存のプラグインが記録したメッセージの流れを追ってみて下さい。この制限に対するワークアラウンドとしては、あるオーケストレーション操作が起動された時に受信メッセージをロギングすることで、そうした手順をキャプチャーすることです。メッセージはJSON シリアライズされていて、ログファイルに容易に書き出せます。例として、私たちがHyper-Vの単体試験で使用したサンプルコマンドをみて下さい。ResourceServerの execute(Command cmd) を呼び出してください。メッセージは再構築されたオブジェクトに直接ディスパッチされます。一番重要なのが、ログからある操作における一連のコマンドの順序がわかるということです。例えば、VM生成前に処理する必要のあるストレージ・コマンドがたくさんありますが、それらには驚くべき名前がついています。CreateCommandはストレージ専用で、StartCommandはVM生成のコマンドです。ログを見ればこうしたサプライズを避けられます。実際に私たちはテスト駆動で開発しています。メッセージがロギングされた後、私たちはプラグインをロードして、受信されるべきメッセージを送るテストを生成することができます。コーディングが完了したら、このコードは単体試験に組み込むことができます。わかったこと、単体試験を計画し、そのテストを通るコードを書くには、ログ出力されるコマンドを使うこと。
• #14: 今後実装される機能と、他の誰かが解決したMLでの開発問題に注目していて下さい。私たちの問題を解決するため進化するCloudStack私たちはストレージが構造的に分割されるまでの間の時間をかせぐため、ストレージについては暫定のソリューションを選択した。NFSベースのセカンダリ・ストレージはオブジェクトストアとイメージサービスの組み合わせで置き換えた。一つの選択肢はSwiftを使うことで、もうひとつは S3によるアプローチだった。これらはフットプリントを絞り込んだHyper-V Server 2012を使用した場合には有利です。なぜなら、そこには通常通りNFSを直接使用できるNFSクライアントがないからです。プライマリ・ストレージ・モデルはより多様な選択を許すようアップデートされている。Hyper-V Server 2012 はSMB サービスを探すので、私たちはハイパーバイザーにSMBストレージを自動的に追加するようしたかった。暫定ソリューションによってこうした手間を省いた。私たちはプライマリ・ストレージにローカルディスクを使った。つまりフェーズ1のプラグインは共有ストレージは手動でマウントする必要がある。私たちはSMBをNFSとして公開するのにWindows サーバーの機能を利用した。それによって、SMB共有ストレージをマウントしたHyper-V サーバーからセカンダリ・ストレージへのアクセスが可能になるでしょう。もし適切はストレージ設計ができれば、他の選択をしたでしょう。同様にSystemVMを作成するのは、各種のオファリングを提供し、作成を簡素化するための開発工数が必要でした。SystemVMはCloudStack管理サーバーに、イメージを保存するセカンダリ・ストレージ、IsolatedネットワークのNAT等のネットワークサービス、コンソールアクセスのサービスを提供します。各ハイパーバイザーには専用のSystemVMがあります。わかったこと、理想の設計をターゲットに据えると、即座に開発工数は増加します。というわけで、私がCloudStackの進化を有効活用したと言うとき、2つの問題に言及しています。私たちは廃止予定のAPIやデザインに開発が関わらないように気をつけました。2つ目は、私たちは他のプロジェクトに参加することで問題を先送りすることができます。同じ事はSystemVMについても言えます。CloudStackはストレージ・モデルを変えるべく一連の斬新な書き換えを実施中です。
• #15: Apache CloudStackではプロジェクトに寄贈できるコードを探しています。これによって訴訟コストを大きく削減出来ます。プロジェクトのコードの所有者に曖昧さがあると、訴訟のきっかけとなります。この法的コストは訴訟費用ではありません。防衛手段に要する開発時間の損失なのです。あなたの製品の立場を改善します。法的リスクは見積が困難であり、採用を躊躇させます。コードの全ての権利がプロジェクトに帰属すると主張することは健全な慣習です。しかし、既存のコピーライトは変更が難しい。コードをApache v2.0 でライセンスすると自動的に著作権をApacheに帰属するわけではありません。上記はApacheライセンスを含むサードパーティ製コードの例です。これらは著作権表示を汚染する可能性があります。このコードの著作権は引き続きサードパーティによって保持されます。これから生じる全ての派生物についても同様です。既存の著作権を移転することは困難です。承諾プロセスにはあなたの組織の法務組織が関与する必要があります。法務処理はコストセンターであり、会社ポリシー準拠の面倒な手続きがあります。その結果、非常に時間がかかります。著作権を開発プロセスに適合させる必要もあります。RAT ビルドツールを非適合ライセンスを除外するよう設定することは可能ですが、設定は自動ではありません。あなたが利用するライブラリー群はプロジェクトに適合したやり方で検査しなければなりません。あなたが作成したコードの所有者は明確でなければなりません。予めライセンス問題に対処することは重要です。少しでも知的所有権について不確かな点を残してはいけません。
• #16: SystemVMは3392番ポートでSSHが構成されていて、CloudStack管理サーバーが生成した鍵を使用します。かわりに、私はハイパーバイザーのコンソールを使います。パスワードは 6m1ll10n です。-　トラブル時はこの情報を使ってログファイルをチェックして下さい。XenServerにはiptablesで定義された追加ルールがあります。これらのルールをオフにする時は気を付けて下さい。Mavenプロジェクトを Eclipse にインポートするには m2e を使用して下さい。Maven を Eclipse がアタッチできるよう、デバッグ可能なサスペンド状態で起動するには、export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=y参考：http://www.mojavelinux.com/blog/archives/2007/03/remote_debugging_with_jetty/Log4j のロギングを変更するには:出力レベルをINFO から TRACEへ:%s/INFO/TRACE/g