/割当

今日のsig-networkミーティングで話し合った後、v1.10ではAlphaをターゲットにしています。

cc @ kubernetes / sig-network-misc

設計上の議論は解決されていません。これは現在v1.11を対象としているように見えますか？ そうでない場合は更新してください。

v1.10の時間枠を逃したようです。 次のSIG-Networkミーティングでそれを提示して、v1.11チケットを取得できるかどうかを確認しますか？

@ m1093782566
1.11でこれについて何か計画はありますか？

もしそうなら、あなたはその機能が適切なもので最新であることを確認してください：

• 説明
• マイルストーン
• 譲受人
• ラベル：
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecycle stale

/ポリシーによる

現在のこの機能にはマイルストーンがないため、チェックインして、Kubernetes1.12でこれに関する計画があるかどうかを確認したいと思います。

その場合は、この問題が最新であり、次のすべての情報が含まれていることを確認してください。

• 1行の機能の説明（リリースノートとして使用できます）：
• 主な連絡先（譲受人）：
• 責任あるSIG：
• デザイン提案リンク（コミュニティリポジトリ）：
• e2eおよび/または単体テストへのリンク：
• レビュー担当者-（LGTMの場合）2人以上のレビュー担当者（コード領域のOWNERSファイルから少なくとも1人）にレビューに同意してもらうことをお勧めします。 複数の企業のレビュー担当者が優先：
• 承認者（機能が属するSIG /エリアからの可能性が高い）：
• 機能ターゲット（どのターゲットがどのマイルストーンに等しいか）：
  
  
  
  • アルファリリースターゲット（xy）
  
  
  • ベータリリースターゲット（xy）
  
  
  • 安定した放出目標（xy）
  
  

以下を設定します。

• 説明
• 譲受人
• ラベル：
  
  
  
  • ステージ/ {アルファ、ベータ、安定}
  
  
  • sig / *
  
  
  • 種類/機能
  
  

この機能が適切に更新されたら、してください明示的にpingを@justaugustus、@ kacole2、@robertsandoval、@ rajendar38ノートに含まれる準備ができていることをKubernetes 1.12のためのスプレッドシートを追跡する機能。

機能のフリーズは明日7月31日です。その後、機能の問題が不完全な場合は、マイルストーンに例外リクエストを受け入れる必要があり

さらに、次の関連する期限に注意してください。

• ドキュメントの締め切り（オープンプレースホルダーPR）：8/21
• テストケースのフリーズ：8/28

機能のすべてのPRに、関連するリリースノートも含まれていることを確認してください。

ハッピーシップ！

PSこれは自動化によって送信されました

こんにちは@ m1093782566
この拡張機能は以前に追跡されているため、チェックインして、Kubernetes1.13のステージを卒業する計画があるかどうかを確認したいと思います。 このリリースは、より「安定した」ものを目標としており、積極的なタイムラインがあります。 次の期限に間に合うと確信できる場合にのみ、この拡張機能を含めてください。
ドキュメント（オープンプレースホルダーPR）：11/8
コードスラッシュ：11/9
コードフリーズの開始：11/15
ドキュメントの完成とレビュー：11/27

1.13拡張機能追跡シートに含める必要がある場合は、将来の追跡とping @ kacole2のために元の投稿のマイルストーンを更新してください。

また、すべての新しい拡張機能がKEPと連携することも奨励しています。 KEPが作成されている場合は、元の投稿でKEPにリンクするか、KEPを開発する機会を利用してください。

ありがとう！

sig-networkごとに、1.13の時間枠で改訂されたKEPを取得することを検討していますが、コードは取得していません。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecycle stale

@ m1093782566こんにちは-私は1.14の拡張機能のリーダーであり、この問題をチェックして、1.14リリースで計画されている作業（ある場合）を確認しています。 拡張機能のフリーズは1月29日であり、すべての拡張機能にはKEPが必要であることを思い出してください。

@claurence

https://github.com/kubernetes/enhancements/pull/640を確認して

@ m1093782566ありがとう！ 説明によると、この機能は1.15のアルファ版を対象としているようです。そのため、1.14を追跡するものはありませんが、正しくない場合はお知らせください。

@claurence 1.14でアルファ版を入手できれば、それを期待していました。 @ m1093782566 1.14に間に合うようにCRDのリワークを完了すると思いますか？

@johnbelamaricに感謝します-アルファマイルストーンを作成するために、この問題のオープンPRはありますか？

https://github.com/kubernetes/kubernetes/pull/72057およびhttps://github.com/kubernetes/kubernetes/pull/72046

@claurence 1.14でアルファ版を入手できれば、それを期待していました。 @ m1093782566 1.14に間に合うようにCRDのリワークを完了すると思いますか？

試してみます。

@ m1093782566 @johnbelamaricこんにちは-この問題のKEPはまだ「保留中」としてマークされていることに気づきました

これは実装可能です。更新する必要があります。 @ m1093782566まだ
これにより、3月7日のコードが凍結される可能性があると思いますか？

2019年2月11日月曜日午前9時14分クレアローレンス[email protected]
書きました：

@ m1093782566 https://github.com/m1093782566 @johnbelamaric
https://github.com/johnbelamaricこんにちは-このKEPに気づきました
問題はまだ「保留中」としてマークされています-KEPを作成するにはさらに何が必要ですか
実装可能ですか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/enhancements/issues/536#issuecomment-462411649 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AJB4s_Wfb4vO9nwzOBwV9xPnYpAu6eZoks5vMaTYgaJpZM4RaMvm
。

@johnbelamaric

ありがとう。 1.14コードのフリーズ日を作成できるかどうかはわかりませんが、現在取り組んでいます。

/ Assign @thockin
APIレビュー用

@vishhシャドウ

@johnbelamaric @ m1093782566 @thockin KEPを実装可能なステータスにPRしてください。 参照： https ：

＃845で行われました

@claurenceこれは1.15にリターゲットされました。 再割り当てできますか（権限がありません）？

/ milestone v1.15

このためのAPIレビューをシャドウイングすることに興味があります...次の四半期

こんにちは@johnbelamaric 、私は1.15のエンハンスメントリードです。 この機能は1.15でアルファ/ベータ/安定ステージを卒業する予定ですか？ 適切に追跡してスプレッドシートに追加できるように、お知らせください。

コーディングを開始したら、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。

@ kacole2

はい、v1.15を対象としています。関連するk / kのPRは、 https ：

私の友人@guanyudingと私はそれを進めます。

ありがとう！

@ m1093782566 Kubernetesv1.15マイルストーンに含まれる拡張機能についてKEPレビューを行っています。 KEPを確認した後、現在、 KEPテンプレートごとに必要な情報であるテスト計画と卒業基準が欠落しています。 KEPを更新して、Kubernetes1.15拡張フリーズの日付が2019年4月30日になる前に必要な情報を含めてください。 ありがとう。

@ m1093782566 、Kubernetes 1.15の拡張フリーズが過ぎましたが、期限に拡張例外を提出してください。 ありがとう。 @claurence

/マイルストーンクリア

こんにちは@ m1093782566 、私は1.16エンハンスメントシャドウです。 この機能は1.16でアルファ/ベータ/安定ステージを卒業する予定ですか？ 1.16トラッキングスプレッドシートに追加できるようにお知らせください。 卒業していない場合は、マイルストーンから削除し、追跡ラベルを変更します。

KEPを確認した後、現在、 KEPテンプレートごとに必要な情報であるテスト計画と卒業基準が欠落しています。 KEPを更新して、Kubernetes1.16拡張フリーズの日付が2019年7月30日になる前に必要な情報を含めてください

マイルストーンの日付は、Enhancement Freeze7 / 30およびCodeFreeze8 / 29です。

ありがとう。

https://github.com/kubernetes/enhancements/pull/1132に追加された卒業基準

こんにちは@ m1093782566、1.17エンハンスメントシャドウはこちら！ 🙂

*この拡張機能が1.17でアルファ/ベータ/安定に移行するかどうかを確認するために連絡したかったの*
この拡張機能を1.17トラッキングシートに追加できるように、お知らせください。

KEPにはテストプランがないことに注意してください。

ありがとう！

🔔フレンドリーなリマインダー

• 現在のリリーススケジュールは
  
  
  
  • 9月23日月曜日-リリースサイクルが始まります
  
  
  • 10月15日火曜日、EODPST-拡張機能のフリーズ
  
  
  • 11月14日木曜日、EODPST-コードフリーズ
  
  
  • 11月19日火曜日-ドキュメントを完成させて確認する必要があります
  
  
  • 12月9日月曜日-Kubernetes1.17.0がリリースされました
  
  

• Kubernetes拡張プロポーザル（KEP）は、拡張フリーズがリリースに受け入れられる

  • PRはにマージされます
  • implementable状態の場合
  • テスト計画と卒業基準を含める

• 関連するすべてのk / kPRをこの号に記載する必要があります

@annajung

この拡張機能が1.17でアルファ版に移行することを望んでいましたが、1.17トラッキングシートに追加するのを手伝っていただけませんか。 ありがとう！

ねえ@ m1093782566 、追跡する追跡シートにこの拡張機能を追加します👍

わかりやすいリマインダーについては上記のメッセージを参照してください。KEPにはテストプランがありません。

ねえ@ m1093782566 、可能であれば、testgridのテストへのリンクを含め、追加されたテストを追跡してください。 ありがとう！

ねえ@ m1093782566 、エンハンスメントフリーズ（10月15日火曜日、EOD PST）からわずか5日です。 1.17リリースでこれを卒業できるようにするには、KEPでテスト計画を定義する必要があることをもう1つ覚えておいてください。

また、アルファからベータに移行するためのKEPの卒業基準の下でのこのステートメントの意味を明確にできますか？

E2E tests exist for service topology

他のメンバーが意図を理解するのを助けるための情報は非常にありがたいです！ 再度、感謝します！ ご不明な点がございましたら、お気軽にお問い合わせください。

ねえ@ m1093782566 、残念ながら1.17拡張フリーズの期限が過ぎており、KEPにはまだテストプランがないようです。 この拡張機能を1.17マイルストーンから削除します。

1.17でこれを取得する必要がある場合は、拡張例外を提出できることに注意してください。

/マイルストーンクリア

今日は例外を提出します。 ここにテストプランを追加しました： https ：

@guineveresaengerは本日例外を承認したので、これを1.17マイルストーンに追加します。

/ milestone v1.17

こんにちは@ m1093782566私はv1.17ドキュメントシャドウの1つです。
この拡張機能（またはv1.17で計画されている作業）には、新しいドキュメント（または既存のドキュメントへの変更）が必要ですか？ そうでない場合は、1.17エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

もしそうなら、11月8日金曜日までに予定されているk / website（ブランチdev-1.17）に対するPRを探しているのは、フレンドリーなリマインダーです。現時点では、プレースホルダーPRになる可能性があります。 ご不明な点がございましたらお知らせください。

@ m1093782566

11月8日にドキュメントプレースホルダーのPR期限が近づいています。 k / websitedev-1.17ブランチに対して1つを取得してみてください。

ねえ@ m1093782566 1.17ここにエンハンスメントシャドウ！ 👋この機能強化がどのように行われているかを確認するために、あなたと一緒にチェックインするために連絡を取ります。

k / k PRを提供していただき、ありがとうございます。トラッキングシートに次のkubernetes / kubernetes＃72046を追加しました。 同様に追跡する必要がある他のk / k PRはありますか？

また、コードのフリーズに近づいていることを示すもう1つのわかりやすいリマインダーです（11月14日）。

@irvifadocsプレースホルダーPRが送信されました

こんにちは@ m1093782566 @johnbelamaric 、明日は1.17リリースサイクルのコードフリーズです。 k / kPRがマージされていないようです。 1.17トラッキングシートでは、この拡張機能にAt Riskフラグを付けています。

必要なPRはすべて14日（木）のEoDで統合されると思いますか？ その後、例外を除いて、リリースブロッキングの問題とPRのみがマイルストーンで許可されます。

参考までに：私は数日前にこの機能に関する中国語の記事を書きましたが、それは中国で大きな反響を呼び、今では英語に翻訳しましたhttps://imroc.io/posts/kubernetes/service-topology-en/

あなたの忍耐と慎重に検討@thockin @andrewsykim @johnbelamaric @robscottためにあなたのすべてに感謝

この機能を宣伝するために、より多くの時間と労力を費やします。 私はいくつかのTODOをリストしました：

• KEPを更新する
• サービストポロジをExternalTrafficPolicyに完全に置き換えることができます
• より多くのプロキシをサポートする
• ヘッドレスサービスのサポート（kube-dns / coredns）

クロスAZトラフィックは無料ではなく、現在、Kubernetesでそれを回避するためのツールは実際にはありません。

アマゾンはGBあたり0.02ドルを請求します： //www.lastweekinaws.com/blog/aws-cross-az-data-transfer-costs-more-than-aws-says/

3つのAZを使用すると、内部トラフィックの3分の2が1 GBあたり0.02ドルで請求されます（ターゲットIPのランダムな分散を想定）。

トポロジ対応ルーティングは、同じAZ内のポッドを優先することにより、データ転送を無料に保つための優れた機能になります。

クロスAZトラフィックは無料ではなく、現在、Kubernetesでそれを回避するためのツールは実際にはありません。

アマゾンはGBあたり0.02ドルを請求します： //www.lastweekinaws.com/blog/aws-cross-az-data-transfer-costs-more-than-aws-says/

3つのAZを使用すると、内部トラフィックの3分の2が1 GBあたり0.02ドルで請求されます（ターゲットIPのランダムな分散を想定）。

トポロジ対応ルーティングは、同じAZ内のポッドを優先することにより、データ転送を無料に保つための優れた機能になります。

はい、ほとんどのクラウドベンダーでは、通常、クロスAZトラフィックは無料ではありません。 この機能を楽しみにしましょう。

/割当

/ assign @johnbelamaric @andrewsykim

KEPを更新するつもりですが、ヘッドレスサービスの実装方法について再考し、議論する必要があることがわかりました。

ヘッドレスサービスを処理するために、DNSサーバーはDNS要求のクライアントIPアドレスに対応するノードを知る必要があります。つまり、PodIP->ノードをマップする必要があります。 Kubernetes DNSサーバー（kube-dnsとCoreDNSを含む）はPodLocatorオブジェクトを監視します。 クライアント/ポッドがDNSサーバーにヘッドレスサービスドメインを要求すると、dnsサーバーはPodLocatorを介してクライアントとバックエンドポッドの両方のノードラベルを取得します。 DNSサーバーは、クライアントポッドと同じトポロジカルドメインにあるバックエンドポッドのIPのみを選択し、Aレコードを書き込みます。

初期の設計では、dnsサーバーがPodLocatorを監視して、クライアントとバックエンドポッドの両方のノードラベル（トポロジ情報）を取得していました： When a client/pod request a headless service domain to DNS server, dns server will retrieve the node labels of both client and the backend Pods via PodLocator.

ただし、kube-proxyの現在の実装では、 EndpointSliceを監視してバックエンドポッドのトポロジ情報を取得し、現在のノードを監視してクライアントのトポロジ情報を取得します。 したがって、 PodLocatorはもう必要ありませんが、dnsサーバーはPodLocatorなしでクライアントポッドのトポロジ情報をどのように取得しますか？ ヘッドレスサービスを実装したい場合は、もう一度PodLocatorが必要だと思います😂

@thockin @robscott @andrewsykim @johnbelamaric @ m1093782566

kube-dns / corednsは、ノードメタデータを監視してトポロジ情報を取得できると思いますが、より多くのコンピューティングリソースが必要ですが、kube-proxyとは異なり、各ノードに1つのレプリカがあります。

どう思いますか？ @thockin @andrewsykim

こんにちは、 @ imroc 、私の友人がこの問題を送ってくれました。同じゾーンにリクエストをルーティングするためのcoreDNSプラグインを作成することを考えていたのですが、実際にそうしました。

これは単なるプロトタイプですが、トリックを実行します。
https://github.com/erickfaustino/coredns/blob/inmemory/plugin/k8szoneaware/

これを書いているときに私が持っていた認識：

1-リクエストごとにK8SAPIを使用すると、すべてをキャッシュするよりも遅くなる可能性があります
2- Add、Delete、またはUpdateイベントで、キャッシュされたマップを更新するためにインフォーマーを使用することを考えていました。 （私はまだこの部分を書きませんでした）
3-サービスでアノテーションを使用して適格にする
4-ヘッドレスサービスでのみ使用できます

これがお役に立てば幸いです。できれば、喜んでお手伝いさせていただきます。

@erickfaustinoご協力いただきありがとうございます。 ただし、ここで重要なのは、クライアントのトポロジ情報を取得する方法です。 あなたの考えによると、すべてのポッドとすべてのノードをキャッシュする必要があります（リクエストIPでポッドを取得し、ポッドでnodeNameを取得し、ノードのトポロジを取得します）。これを行うと、corednsは大きなクラスター（5kなど）で多くのリソースを消費しますノードと50k以上のポッド、およびkubeletレポートノードのステータスのため、すべてのノードが頻繁に更新されます。

全体のアイデアは単純です：

1. DNSリクエストからクライアントのソースIPを取得します。
2. クライアントのトポロジ情報を検索します（ホスト名、
   地域、ゾーン...）
3. クライアントのトポロジに従って、要求されたヘッドレスサービスのエンドポイントをフィルタリングします。
4. フィルタリングされたエンドポイントを返します。

今の難しさは第二段階です。 ノード/ノードのメタデータとポッドを監視することを選択した場合、クラスターのサイズが大きくなるにつれて、corednsはより多くのリソースを消費します。

それとも、 PodLocatorをもう一度使用する必要がありますか？ それとも、ヘッドレスサービスは、サービストポロジを実装する価値がありますか？ @thockin @andrewsykim

私見、ヘッドレスサービスをサポートする必要はないかもしれません。人々がサービスtopolgoyサポートを備えたサービスを希望する場合は、別の非ヘッドレスサービスを作成するだけです。 また、これにより、istioのLocality Load Balancingとの競合を回避できます。これは、クラスターDNSがフィルター処理されたエンドポイントのIPを返す場合、パイロットはエンドポイントの完全なリストを取得できないためです。 ただし、パイロットはedsルールを生成し、 DestinationRuleに従ってエンボイに送信する必要があります。たとえば、異なるローカリティにあるエンドポイントに転送するのではなく、そのローカリティに応じてエンドポイントの重みを調整します。

こんにちは@ imroc @ m1093782566-1.18拡張機能のシャドウはここにあります。 チェックインして、この拡張機能が1.18でアルファ版に移行するのか、それとも現在のレベルに大きな変更があるのか​​を確認したいと思います。

現在のリリーススケジュールは次のとおりです。

1月28日火曜日EODPST-拡張機能のフリーズ
3月5日木曜日、EODPST-コードフリーズ
3月16日月曜日-ドキュメントを完成させて確認する必要があります
3月24日火曜日-Kubernetes1.18.0がリリースされました

リリースに含めるには、この拡張機能のKEPがimplementableステータスにマージされている必要があります。 KEPには、卒業基準とテスト計画も定義されている必要があります。

問題の説明に記載されているKEPリンクが古くなっていることがわかります。 更新されたKEPで説明を更新してください。

この拡張機能を含めたい場合は、コーディングが開始されたら、適切に追跡できるように、この問題に関連するすべてのk / kPRをリストしてください。 👍

ここで拡張機能を追跡します： http ：

ありがとう！

@helayoty v1.17ではすでにアルファ版であり、現在不明な点があるため、v1.18では大きな変更はない可能性があります。

@imrocご

cc： @robscott

今日のsig-network呼び出しで説明したように、 @ imrocは、EndpointSlicesがサービスで定義されたtopologyKeysと一致するトポロジフィールドを設定することを保証するPRに取り組みます。 @helayoty明日はその変化をカバーするKEPのPRをしようと思います。 これは、追跡する必要がないほど小さい更新だと思いますが、確かではありません。 少なくとも、1.18ではサービストポロジのAPIが変更されることはないと思います。

@robscottこれはすばらしいことです。もちろん、この小さな変更はサービストポロジのロジックにはまったく影響しません。 情報ありがとうございます。

@ robscott @ imrocパーフェクト1.18にこの問題を含めます

KEPPRと他のk / kPRを共有していただければ幸いです

/マイルストーンv1.18

こんにちは、 @ robscott @imroc @ m1093782566-

ここでセス、ドキュメントは1.18リリースチームに影を落とします。

1.18で計画されているこの拡張作業には、新しいドキュメントや既存のドキュメントへの変更が必要ですか？

そうでない場合は、1.18エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

ドキュメントの更新が必要な場合は、k / website（ブランチdev-1.18）に対するプレースホルダーPRの期限が2月28日金曜日であることを忘れないでください。

ご不明な点がございましたらお知らせください。

@sethmccombsさん、これにはサービストポロジやEndpointSliceドキュメントにいくつかの小さな追加が必要になります。 2月28日までにプレースホルダードキュメントPRを実施します。

ねえ@sethmccombs 、この変更は1.18にはなりません。このリリースの追跡から、

昨日のsig-network呼び出しについて、トポロジ対応ルーティングにアプローチする可能性のある他の潜在的な方法について、良い議論がありました。 それがどうなるかは正確にはわかりませんが、他の潜在的なアプローチを探求する時間が増えるまで、この方向に進みすぎたくはありません。 これはすでにかなり小さな変更になる予定だったので、後でそれを残すことは実際には気付かれないと思います。

とはいえ、将来のリリースでこれを推進することに参加したいので、私はこの問題に自分自身を割り当てています。

/割当

/マイルストーンクリア

こんにちは@ robscott -1.19拡張機能ここをリードします。この拡張機能が1.19で卒業すると思われるかどうかを確認したいと思いますか？

現在のリリーススケジュールは次のとおりです。

• 4月13日月曜日：第1週-リリースサイクルが始まります
• 5月19日火曜日：第6週-拡張機能のフリーズ
• 6月25日木曜日：第11週-コードフリーズ
• 7月9日木曜日：第14週-ドキュメントを完成させて確認する必要があります
• 8月4日火曜日：第17週-Kubernetesv1.19.0がリリースされました

ねえ@palnabarun 、リマインダーをありがとう！ これに代わるものとして、トポロジー対応ルーティングへのより自動化されたアプローチについていくつかの議論がありました。 この拡張機能と密接に関連していますが、最終的には別のKEPになる可能性があります。 この他の潜在的なアプローチを検討しているので、このサイクルでこのKEPに直接的な進展はないと思います。

更新してくれてありがとう@robscott 。 それに応じてトラッキングシートを更新します。 ：+1：

これは優れた機能であり、まさに私が必要としているものです。

特に、次のtopologyKeysを使用しています。

• ["kubernetes.io/hostname", "topology.kubernetes.io/region", "*"]
• ["topology.kubernetes.io/region", "*"]

こんにちは@robscott @imroc @ m1093782566

拡張機能がここをリードします-1.20でこれを計画していますか？ 念のため、EnhancementsFreezeは10月6日です。

説明404のKEPへのリンク、更新していただけますか？ https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0033-service-topology.mdはます-network / 20181024-service-topology.md

ありがとう！
キルステン

ねえ@ kikisdeliveryservice 、1.20でこれを前進させる計画はないと思います。 sig-networkでAPIを簡素化する方法について話し合っていることは知っていますが、 KEP2004で1つのオプションを提案しました。 そのKEPは承認されていませんが、承認されている場合は、このアプローチの進化と潜在的な置き換えを表す可能性があると思います。 残念ながら、この号ではKEPへのリンクを更新するためのアクセス権がありませんが、 @ m1093782566で更新できる可能性がありますか？

@robscottを更新してくれてありがとう、私は自分で説明を更新することができました。 ：+1：この拡張機能は未追跡のままになります。 この変更があった場合は、10月6日までにお知らせください：smile：