Fabric: v2互換の「役割」または同様のもの

あらすじ

執筆時点では、v2ブランチにはGroupクラスがあり、以前は「ロール」、別名「何かを実行するためのホストの束」として知られていたユニットとして機能できるはずです。

ただし、 Groupオブジェクトを整理またはラベル付けする特定の方法はまだありません。 これは、独自の作成方法を使用したい上級ユーザーの純粋なAPIユースケースには十分に「完了」していますが、フレームワークを構築したいCLI指向のユーザーや中級者には何もありません。

別の言い方をすれば、純粋にAPIを使用している場合を除いて、CLIまたはタスク呼び出しビットにそれらを見つける方法がない場合、グループオブジェクトをどこかに置いても意味がありません。

バックグラウンド

v1では、ロールは事実上、単純な文字列ラベルをv2のグループにマッピングする単一のフラットな名前空間であり、実行時にCLIで選択したり（ fab --roles=web,db ）、タスクのデフォルトターゲットとして登録したりできました（ @task('db') \n def migrate(): ）、ホストとよく似ています。

ユーザーはそれらをenv.roledefsで定義しました。これは単純な口述です。 中級から上級の機能は、通常は実行時（プレタスクまたはサブルーチンを介して）、場合によってはモジュールのロード時に変更することを中心に展開されました。

特定のユースケース/ニーズ/サブ機能

• システム内の他の場所で使用/参照するための基本的で単純なマッピング：名前を入力し、 Groupおよび/またはConnectionの反復可能なものを取得します。
  
  
  
  • エイリアシングはしばしばそれに合わせたいので、例えばLexicon代わりにdict 。
  
  
  • 'bundling'などのさらに深い構造。たとえば、 db 、 web 、 lbという名前の直接マッピングがありますが、2番目の層の名前はprodは、常に他の3つの和集合です。 それをLexiconに追加したかどうかはまだ忘れています。 すでにそれを行っている他のマップサブクラスがある可能性があります。
  
  
  • さらに/代わりに、グロブや他の文字列構文のようなものですが、私は個人的にPythonが「文字列型」ではないという事実を利用したいと思っています...
  
  
• 特定の接続がどのグループに属しているかを識別できる便利な「逆マッピング」。
  
  
  
  • 問題：現在、グローバル共有状態がないため、複数の同一のConnectionオブジェクトを技術的に作成できるため、これに対する素朴な答え（IDの使用）は失敗します。
  
  
  • 特に、Groupは、省略形のホスト文字列を指定するだけで、ユーザーに代わって暗黙的にそれらを作成できるためですが、これは便利なオプションにすぎません。
  
  
  • しかし、それはなんとかする必要がありますので、グローバルな状態の制約は、私は、代わりにテスト平等を使用して明白な問題を見ることができないことを考えると例えばif cxn in group場合でも動作しますcxn個別のオブジェクトでありますgroup内の同等のメンバーから。
  
  
  • 頭に浮かぶ唯一のことは、接続からグループへの強力でステートフルなリンク（グループ、複数形である必要があります）がその逆ではなく、それを保持している場合ですが、その理由はわかりません。
  
  
• 以前と強く関連しています：「現在実行中の役割」が何であるかを検査/表示する機能（v1で長い間人々が望んでいたもので、その設計のために重要でした）
  
  
  
  • 主な問題は、これが実際には2つの半明確な質問であるということです。「一般的に言えば、現在のホスト部分はどの役割ですか」（基本的には、逆引き参照の以前の使用例）だけでなく、「どの役割が実行機械は特に対抗するように求められました」。
  
  
  • 言い換えると、ロールA、B、およびCに属する特定のホスト「foo」：コンテキストが「foo」であるが、「ロールAで実行」の要求のために実行された特定のタスク内で、ユーザーは次のことを探しています。 「A、B、C」（全体的に「foo」の役割）または単に「A」（現在実行中の役割）の答えですか？
  
  
  • これは、私が覚えている機能要求が2つを混同しているにもかかわらず、実際には2つの異なるAPI呼び出しのように感じます。
  
  
• CLIでのターゲットの選択、グローバルおよび/またはタスクごと
  
  
  
  • 「すべてのタスクが定義したものの上にあるフラグ」を説明するためのInvokeのCLIシステムの拡張は、これに役立つか、必要な場合があります。 実際、これはpyinvoke / invoke＃205の領域にしっかりと分類されるため、以前よりも優先度が高くなりました（かなり高かった）。
  
  
• 同上タスクレベルのデフォルト
  
  
  
  • タスクレベルのターゲットのデフォルトは、実際には、接続、接続、グループobj、グループobj、または_to_グループobjを評価する名前のいずれかになります（間違いなく、このチケットに直接関係するのは最後のものだけです）。
  
  
• 同上コレクションレベルのデフォルト（v2の新機能！）
  
  
  
  • つまり、「$ submodule内のすべてのタスクは、デフォルトでdbロールに対して実行されます」
  
  
  • 前のポイントと同じ取引-このデフォルトでは、文字列キーだけでなく、さまざまな値を許可する必要があります。
  
  
• 本当にこれと一緒に行きたいOOアプローチによって可能になった他に新しくてエキサイティングなものはありますか？ ChefやAnsibleのようなシステムを完全に再発明することではなく、ビルディングブロックと上級ユーザーの有効化に重点を置く必要があることを忘れないでください。

実装のアイデア/懸念

• 構成システムをメインストレージベクトルとして使用した場合、値はyaml、jsonなどに保存できるようにプリミティブになりたいのですが、それは「すべてのグループ/接続kwargsを大きなolに保存する」で終わるワームの缶です。 list-o-dicts」など。
• 定義が主にPythonであると予想される場合は、単に「グループオブジェクトのインスタンス化」と言うことができ、そのデータを構成システムにマージするか、何らかの方法でスタンドアロンのままにするかを選択できます。
  
  
  
  • 文字通りすべてをネストされた構成辞書に詰め込むと、悪いニュースにつながるように感じるので、後者の方が好きだと思います。
  
  
• エイリアシングやバンドルなどのより深い構造は、複雑さと順序の問題を追加します（つまり、key1の値がグループであるがkey2の値がkey1である、些細なエイリアス設定を想像してください。ここで、key2を解決またはチェックするために構造を2回クロールする必要があります）
  
  
  
  • ただし、ほとんどの場合「Pythonで実行」アプローチを採用すると、構成システムのAPIによく似たものになります。宣言型構造から始めることができますが、初期設定後のメソッド呼び出しによってそれ以上のことが可能になります。 ひどいとは思わない？ 編集：そして私はそれがとにかくレキシコンが正確にどのように機能するかだと思います。
  
  
• フォーマットに関係なく、上級ユーザーが外部ソースなどからオンザフライでそれを生成する方法を理解する必要があります。 これに加えて、エイリアシングなどの問題は、これをどこかに「格納」された単純な構造ではなく、それを生成するために呼び出される1つまたは複数のオブジェクトのAPIとして必要とする可能性があることを意味します。
  
  
  
  • 役割/グループの選択から「下向き」に作業し、「ユーザーが提供したものを実行可能なターゲットの単位に変える」ための最高レベルのAPIに到達したいと思うかもしれません。そのAPI呼び出しの実装を完全に制御できます。 そうすれば、いつものように、便利な一般的なケースのように感じられるが、「それを行うための1つの方法」として明確にマークされているものを提供できます。
  
  
  • @RedKriegは持って気の利いたアイデア我々が持っているところ、これらの線に沿っての@groupのように@task 、および機能は、作業の実行単位ではなく、代わりにグループがオブジェクトをもたらします。
  
  
  • このアプローチは、タスク階層（コレクション）をネイティブに再利用します。これは、実用的（車輪の再発明）でエレガントです（実際のケースでは、役割/グループ定義は、それらを使用するタスクに非常に密接にマッピングされることが多いためです！）
    
    
    
    
    
    • また、ルートコレクションレベルで定義を記述できるため、グループがタスクにマップされていない場合でもうまく機能します。 簡単なピーシー。
    
    
    
  
  
  • これが各関数から単一のグループを返すのに最適なのか、複数のグループ（または接続）を生成する機能が必要なのか、それとも装飾された関数としてではなく、API呼び出しとして行うのが最適なのかは私にはわかりません。コレクション（コレクションレベルの構成の保存方法など）。
  
  
  • たとえば、グループ/ロールデータが動的で、Fabricの外部にあるユースケースでは、ここで解決する必要があります（そのため、最初にこのスペースの最高レベルのAPIを特定する必要があることを前述しました。次に、それがどのようにメッシュ化されるかを確認する必要があります。この中級レベルのアイデアで。）