付録E プロファイルの自動タグ付け
イントロスペクションプロセスでは、一連のベンチマークテストを実行します。director は、これらのテストからデータを保存します。このデータをさまざまな方法で使用するポリシーセットを作成することができます。以下に例を示します。
- ポリシーにより、パフォーマンスの低いノードまたは不安定なノードを特定して、オーバークラウドで使用されないように隔離することができます。
- ポリシーにより、ノードを自動的に特定のプロファイルにタグ付けするかどうかを定義することができます。
E.1. ポリシーファイルの構文
ポリシーファイルは、JSON 形式で、ルールセットが記載されます。各ルールは、description、condition、action を定義します。
説明
これは、プレーンテキストで記述されたルールの説明です。
例:
"description": "A new rule for my node tagging policy"
conditions
condition は、以下のキー/値のパターンを使用して評価を定義します。
- field
- 評価するフィールドを定義します。フィールドの種別については、「プロファイルの自動タグ付けのプロパティー」を参照してください。
- op
評価に使用する演算を定義します。これには、以下が含まれます。
-
eq: 等しい -
ne: 等しくない -
lt: より小さい -
gt: より大きい -
le: より小さいか等しい -
ge: より大きいか等しい -
in-net: IP アドレスが指定のネットワーク内にあることをチェックします。 -
matches: 指定の正規表現と完全に一致する必要があります。 -
contains: 値には、指定の正規表現が含まれる必要があります。 -
is-empty: フィールドが空欄であることをチェックします。
-
- invert
- 評価の結果をインバージョン (反転) するかどうかを定義するブール値
- multiple
複数の結果が存在する場合に、使用する評価を定義します。これには、以下が含まれます。
-
any: いずれかの結果が一致する必要があります。 -
all: すべての結果が一致する必要があります。 -
first: 最初の結果が一致する必要があります。
-
- value
- 評価内の値を定義します。フィールドと演算の結果でその値となった場合には、条件は true の結果を返します。そうでない場合には、条件は false の結果を返します。
例:
"conditions": [
{
"field": "local_gb",
"op": "ge",
"value": 1024
}
],Actions
action は、condition が true として返された場合に実行されます。これには、action キーと、action の値に応じて追加のキーが使用されます。
-
fail: イントロスペクションが失敗します。失敗のメッセージには、messageパラメーターが必要です。 -
set-attribute: Ironic ノードで属性を設定します。Ironic の属性へのパス (例:/driver_info/ipmi_address) であるpathフィールドと、設定するvalueが必要です。 -
set-capability: Ironic ノードでケイパビリティーを設定します。新しいケイパビリティーに応じた名前と値を指定するnameおよびvalueのフィールドが必要です。同じケイパビリティーの既存の値は置き換えられます。たとえば、これを使用してノードのプロファイルを定義します。 -
extend-attribute:set-attributeと同じですが、既存の値を一覧として扱い、その一覧に値を追記します。オプションのuniqueパラメーターが True に設定すると、対象の値がすでに一覧に含まれている場合には何も追加されません。
例:
"actions": [
{
"action": "set-capability",
"name": "profile",
"value": "swift-storage"
}
]E.2. ポリシーファイルの例
以下は、適用するイントロスペクションルールを記載した JSON ファイル (rules.json) の一例です。
[
{
"description": "Fail introspection for unexpected nodes",
"conditions": [
{
"op": "lt",
"field": "memory_mb",
"value": 4096
}
],
"actions": [
{
"action": "fail",
"message": "Memory too low, expected at least 4 GiB"
}
]
},
{
"description": "Assign profile for object storage",
"conditions": [
{
"op": "ge",
"field": "local_gb",
"value": 1024
}
],
"actions": [
{
"action": "set-capability",
"name": "profile",
"value": "swift-storage"
}
]
},
{
"description": "Assign possible profiles for compute and controller",
"conditions": [
{
"op": "lt",
"field": "local_gb",
"value": 1024
},
{
"op": "ge",
"field": "local_gb",
"value": 40
}
],
"actions": [
{
"action": "set-capability",
"name": "compute_profile",
"value": "1"
},
{
"action": "set-capability",
"name": "control_profile",
"value": "1"
},
{
"action": "set-capability",
"name": "profile",
"value": null
}
]
}
]この例には 3 つのルールが含まれます。
- メモリーが 4096 MiB 未満の場合にイントロスペクションが失敗する。このようなルールを適用して、クラウドに含まれないようにノードを除外することができます。
- ハードドライブのサイズが 1 TiB 上のノードの場合は swift-storage プロファイルが無条件で割り当てられる。
-
ノードのハードドライブが 1 TiB 未満であるが 40 GiB よりも大きい場合はコンピュートノードかコントロールノードかのいずれかです。
openstack overcloud profiles matchが後ほど最終的に判断を下せるように 2 つのケイパビリティー (compute_profileおよびcontrol_profile) を割り当てます。これを機能させるには、既存のプロファイルのケイパビリティーを削除してください。削除しない場合は優先順位が設定されています。
他のノードは変更されません。
イントロスペクションルールを使用して profile 機能を割り当てる場合は常に、既存の値よりこの割り当てた値が優先されます。ただし、既存のプロファイル機能があるノードについては、[PROFILE]_profile 機能は無視されます。
E.3. ポリシーファイルのインポート
以下のコマンドで、ポリシーファイルを director にインポートします。
$ openstack baremetal introspection rule import rules.json
次にイントロスペクションプロセスを実行します。
$ openstack baremetal introspection bulk start
イントロスペクションが完了したら、ノードとノードに割り当てられたプロファイルを確認します。
$ openstack overcloud profiles list
イントロスペクションルールで間違いがあった場合には、すべてを削除できます。
$ openstack baremetal introspection rule purge
E.4. プロファイルの自動タグ付けのプロパティー
プロファイルの自動タグ付けは、各条件の field の属性に対する以下のノードプロパティーを評価します。
| プロパティー | 説明 |
|---|---|
|
memory_mb |
ノードのメモリーサイズ (MB) |
|
cpus |
ノードの CPU の合計コア数 |
|
cpu_arch |
ノードの CPU のアーキテクチャー |
|
local_gb |
ノードのルートディスクのストレージの合計容量。ノードのルートディスクの設定についての詳しい説明は、「ノードのルートディスクの定義」を参照してください。 |

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.