1つのバグの物語(#1653967)

アブストラクト :ばかげたバグをキャッチする実際の管理者の生活からの本当の物語。

有益な部分:依存関係の依存関係を過小評価しないでください。



エントリー



実験室でのOpenstack MitakaからOpenstack Newton(新しいバージョン)への社内アップグレード。 構成ファイルのいくつかの非推奨オプション、keystoneはeventletからWSGIに移動し、haproxyで既存の構成を破壊しました。 典型的な「ipv6 listen」のため、Apacheはスターで同じ使用ポートのhaproxyと競合しませんでした(1つはipv6をリッスンし、もう1つはipv4のみ)。 アップストリームはありませんでした...しかし、物語はそれについてではありません。



主な問題が解決された後、Nova(Openstackコンポーネントの1つ)が起動時にクラッシュし始めました: ConfigFileValueError: Value for option url is not valid: invalid URI: 'http://neutron-server.example.com:21345'.



。 とても奇妙でした。 設定で100,500のオプションが変更されたことを考えると、使用すべきではない古いオプションを使用している疑いがあります。 ただし、ドキュメントには、オプションの例はurl = http://controller:9696



ます。



デバッグ



明らかなデバッグ手順:



合計で、バグ:ホスト名にハイフンが存在すると、ConfigFileValueErrorが発生します。 報告されたバグ: bugs.launchpad.net/ubuntu/+source/nova/+bug/1653967



これがバグであることを確認してください:RFC3986は次のように主張しています:

 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reg-name = *( unreserved / pct-encoded / sub-delims ) host = IP-literal / IPv4address / reg-name
      
      





(これは、ホストでハイフンを使用できるというBNF表記です)。



とにかく私たちは皆これを知っていますが、常にダブルチェックする方が良いです。



エラーを報告するコードを調べる:



  try: return convert(opt._get_from_namespace(namespace, group_name)) except KeyError: # nosec: Valid control flow instruction pass except ValueError as ve: raise ConfigFileValueError( "Value for option %s is not valid: %s" % (opt.name, str(ve)))
      
      





エラーは、urlとnovncproxy_base_urlの2つのオプションで発生しました。 エラーは同じですが、2番目の方がgrepの方が便利です。 二番目を探し始めます。 コードでの定義は次のとおりです。



  cfg.URIOpt( 'novncproxy_base_url', default='http://127.0.0.1:6080/vnc_auto.html', deprecated_group='DEFAULT', help="""
      
      





うん。 cfgはfrom oslo_config import cfg



。 oslo.configは、構成を操作するためのOpenstackライブラリーです。 生っぽい。



見る:



 class URI(ConfigType): ... def __call__(self, value): if not rfc3986.is_valid_uri(value, require_scheme=True, require_authority=True): raise ValueError('invalid URI: %r' % value)
      
      





突然:



 >>> import rfc3986 >>> rfc3986.is_valid_uri('http://test.com') True >>> rfc3986.is_valid_uri('http://test-test.com') False
      
      





おっと 混乱。 ただし、 github.com / sigmavirus24 / rfc3986 / issues / 11があります

バグは長い間修正されています。 バージョン0.2.2で。 そして、ホスト上にあります:



 apt-cache policy python-rfc3986 python-rfc3986: Installed: 0.2.0-2 Candidate: 0.2.0-2 Version table: *** 0.2.0-2 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status
      
      





しかし、zestyの最新バージョンにはバージョン0.3.1-2があり、このような問題はありません。



さらなる手続き



むかしむかし、バグが発生しました。 彼はしばらくそこにいました、そして彼は直されました。 しかし、この間、バグのあるコードはブロックされ、バグの修正に誰も注意を払わず、バグのあるバージョンは何年もdebリポジトリに残っていました。 彼女は誰も気にしませんでした-oslo.configとnovaの2つのコミットが起こるまで:



 commit 45ee2bed52a57b9801435b43ad45d8f50204580d Author: Masaki Matsushita <glass.saga@gmail.com> Date: Mon Sep 28 20:28:28 2015 +0900 Add URIOpt This change add URIOpt which validates string as URI. Closes-Bug: #1500398 Change-Id: Ie8736b8654b9feb2a2b174159f08dbea03568d84
      
      





 commit 6091de77eda12286786e28ae4f0779e7efc54634 Author: Maciej Szankin <maciej.szankin@intel.com> Date: Thu Jul 28 10:30:59 2016 -0500 Improve consistency in VNC opts * Updated header flags * Moved all vars to list * Removed possible values and related options sections where they were not needed * Changed IntOpt to PortOpt where needed Change-Id: I3255a867091f8e14c907c7fde9a2aa3abc249ae9 Implements: Blueprint centralize-config-options-newton
      
      





このコミットは、UriOptによってStrOptから行われ、python-rfc3986を使用して(oslo.conf経由で)開始されました。 古いバージョンのpython-rfc3986がブロックされたため、ソフトウェアで予期しないリグレッションが発生しました。



ボーナス:修正方法



通常、このような場合、新しいバージョンへのアップグレードが簡単な場合(他の問題が発生しない場合)、新しいバージョンの配布キット(この場合は、ubuntu-17.04などのまだリリースされていないzesty)からパッケージを選択します。 適切に実行されているプラ​​イベートリポジトリに(そのまま)配置し、サーバーのインストール/構成時に使用します。 そのようなパッケージが本来存在しなかった場合、CIジョブを構成してパッケージ化し、(適切なリポジトリに)公開します。 このオプションが使用できない場合(互換性のない変更など)、UriOptではなくStrOptを作成するnovaのパッチキューに別のパッチを追加します。 これは、独自のパッチを使用してubuntuパッケージからnovaを再構築することを意味します。 これはCIによって行われ、CIは独自のプライベートリポジトリにパッケージを公開します。



小さな炎



そして、この問題は独自の環境でどのように解決されますか? 誰もが間違いを犯します(そうでなければ、バグのないソフトウェアができます)。 最初のレベルのサポートでエラーが修正された後、インストールされたバージョン、更新、および契約に関する突合せの後、コードを調べることができる実際の資格を持つ人まで、2番目のレベル、3番目のレベルなどのサポートに到達します。 彼は問題を見つけて修正しました。 そのバグ修正の見積もりは何ですか? 最初のレベルに2時間、2番目に1時間、問題を調査するための営業日、修正するための別の営業日、リリースとテストするための別の日。 これは完璧なシナリオです。 実際には、私の最も楽観的な見積もりは、「修正された半年で次のリリース」に変わる週について語っています。



オープンソースプロジェクトで、自分で問題を解決するのにどれくらいかかりましたか? 〜14:30、今日問題が発見され、ランチパッドで報告しました。 15:20には中毒の問題について既に知られていましたが、15:30にはpython-rfc3986の新しいバージョンにはそのような問題がないことが確認されました。 16:50(キプロスの時間による)に、私はこの投稿をHabrで書き終えました。



All Articles