Proposal: Fix inconsistent DNS driver API implementations
- 主要言語
- Python
- スター
- 2.1k
- フォーク
- 931
- 平均マージ
- 1日 2時間
- マージ済み PR(30日)
- 4
説明
## Summary
While comparing the LuaDNS driver to other DNS drivers, I noticed that there are a number of subtly incompatible implementations sharing an otherwise common API which limit portability between providers.
For example, some drivers use empty strings to represent apex/naked records (e.g. example.com.), while others use `None`. Both categories of drivers employ explicit unit testing to confirm their preferred `Record.name` value.
Similarly, some drivers want `Record.name` as a rooted FQDN (e.g. `"host.example.com."`), others as an unrooted FQDN (e.g. `"host.example.com"`), and still others as a bare host name (e.g. `"host"`).
## Proposal
Assuming that the **libcloud** DNS class/driver APIs are intended to provide a consistent interface for users and drivers should provide logic within themselves to adapt the common objects and interfaces for their respective services, I propose the following:
1. Add common logic to the `Record` class to standardize apex/naked record names on the empty string (or `None`).
2. Add common logic to the `Record` class to enforce that `.name` represents the host name, without the domain suffix. This would likely involve adding new `.fqdn` and `.hostname` properties to expose rooted and unrooted FQDN strings, respectively.
- For the sake of compatibility with existing uses, `__init__()` would accept a rooted/unrooted FQDN, a bare host name, or `None`.
3. ~~Refactor `Record.update()` to leverage common code to enforce the items above, while being kind to existing users.~~
4. Expand DNS driver unit tests to validate data sent *to* the provider. Presently, it appears that testing primarily validates the formatting of (canned) responses received *from* a provider.
コントリビューションガイド
調査の方向性
まず DNS Record クラスとその update() メソッドを読み、次に提案で言及されている既存の DNS ドライバーのユニットテストを比較します。ドライバーがプロバイダーへのリクエストとレスポンス向けに Record.name をどのようにフォーマットしているかを追跡します。完了には、合意された共通の命名 API、互換性の動作、およびプロバイダーに送信されるデータを対象とするテストが必要ですが、提案では具体的なファイルが特定されておらず、設計も確定していません。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- backend-api-design, networking
- issue の種類
- リファクタリング
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100