Openstack provider clean-up

オープン
#691 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
go
領域
backend, cloud

調査の方向性

pkg/cloudprovider/provider/openstack/helper.go の217行目付近にあるネットワーク検索、184行目付近にあるセキュリティグループ検索、416行目付近にあるデフォルトサブネットのロジックから始めてください。OpenStack API の使用箇所と、サブネットの挙動の根拠を追跡してください。検索経路が明確かつ効率的で、デフォルトサブネットの挙動がコメントで正当化されているか、意図された provider の挙動と一貫するようにされていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

kind/cleanup priority/low sig/cluster-management

This issue is to do some clean-up in the openstack provider logic, that in some cases is not very clear or optimal. A few examples:

In order to get a network by name or ID we iterate through all networks instead of getting it directly with the proper API call:
https://github.com/kubermatic/machine-controller/blob/master/pkg/cloudprovider/provider/openstack/helper.go#L217

Same applies for security groups:
https://github.com/kubermatic/machine-controller/blob/master/pkg/cloudprovider/provider/openstack/helper.go#L184

The logic we use to get the default subset is a bit obscure: if we have just one subnet in the network provided in input we return it otherwise we obtain the subnets from the API and we return the first if any or we throw an error. If there is a reason behind that, I have some doubts, we should at least comment it properly.
https://github.com/kubermatic/machine-controller/blob/master/pkg/cloudprovider/provider/openstack/helper.go#L416

主要言語
Go
スター
325
フォーク
140
平均マージ
4時間 3分
マージ済み PR(30日)
13

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

kubermatic/machine-controller のほかの issue

kubermatic/machine-controller の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。