はじめに
以前 TerraformのProvider Official化 はじめてみました 記事を書いたのでその続きです。
弊社のサービスである Enterprise Cloud 2.0 のProviderをOfficial化しようとしていて、ほぼその目処がついたので、そこまでにどんな流れがあったのかをまとめてみようと思います。
改めてProviderとはなにか？
ProviderとはTerraformのプラグインのようなものであり、これを使うことで様々なサービスをTerraformから制御できるようになります。世の中に色々記事があるのでそれを見ていただくほうが良いかなと思います。
で、現在私どもの作ったProviderは以下の２種類があります。
前者が Enterprise Cloud 2.0 のものであり、後者は Flexible InterConnect という同じく弊社サービスのものです。
独自な構築自動化ツールとか作らずにこのような形でどんどん広げていければ弊社サービスも少しは使いやすくなるかな・・・と思いこんな取り組みをチームでやってきました。
今回やろうとしているのは前者を Community Provider から Official Provider に昇格させようというものです。
Official化すると何が良いのか？
terraform init という初期設定コマンドを実行するだけで、Providerを使えるようになります。
現時点で Enterprise Cloud なProviderは Community Provider としてTerraformサイトに登録自体はされていますが、この状態ではバイナリをダウンロードして所定の位置に配置しないといけません。実質野良Providerです。
Officialになるとその手間を省いてくれるので使い勝手が良くなります。
とはいえ、 こういう取り組み もあったりするのでCommunity ProviderもいずれはRegistryから引けるようになるかもしれませんけど。
現時点では無理っぽいですけどね。実際に ここで 調べてみたけど無いっぽいので。
前回の記事のおさらい
前回の記事では、
- 申し込む
- その際Provider認証のための情報を渡した
- Hashicorp側での処理が進んだら課題をGitHub Issueに切ると宣言があった
という状態でした。
Official化の現状は？
さて、今どうなっているのか。
ということで、実はまだ少しタスクが残っています。
ではここから、実際にどういうIssueが切られたのか、またそれにどう返していったか・・・を書いてみたいと思います。
Issue その1
予告通り実際にIssueが作られました。 2019/11/27 のことでした。
その内容が [https://github.com/nttcom/terraform-provider-ecl/issues/27] です。
いずれリポジトリも移行しちゃうとリンク元がなくなる（メンテ性を考えて消すような気がするので）かもしれませんので、そこから引用しつつ、どういう対応をしていったかをQ&A形式にして書いておこうと思います。
実際にどんな変更をしたかは、このリポジトリのPRを見て頂ければより明確にわかるのですけどね。（消えるかもということで）
ここでいう Q&A とは
- Q = HashiCorpからの依頼/質問・・・の相当要約
- A = こちらの回答
です。
I was able to get the acceptance tests running but many of the tests are failing due to some environment variables missing. Here’s my test output, could you provide the addition environment variable because we will beed to get all the tests passing before the first release.
Q: AccTestめっちゃコケるんだけど？
A: 直します
これ以外ないです。
ちなみに AccTeest というのは正確ではなく Acceptance Test になります。
この Acc は 実際に対向のサービスにリソースを作って → アサーション（作られたリソースのパラメータとか正しく反映されてる？)して → それを消す という流れのテストです。
ひたすらこのTestがコケていたところを直しました。
コードの問題というよりタイミング問題だったり、あとは弊社サービスの提供リージョン特有の問題だったりといろいろ有りました。
この部分はこの後も紆余曲折あったので、記事の後半でも触れたいと思います。
The CHANGELOG formatting will have to be updated to conform to the standard provider format since the changeling is updated by a bot during the release it must be in a certain format. With the AWS provider changelog as an example, the version of the next release should be tagged as “1.0.0 (Unreleased)” and will then be updated with a date by the release-bot. You should also include a list of provider objects in this first release.
Q: CHANGELOGのフォーマットが僕らの期待するものと違うよ
A: 直します
これもフォーマットを統一するという意味で修正をしました。
There are a number of mock tests in the provider, what’s the reason for this?
Q: Mock Testという物があるんだけどなんで？
A: 作成にすごく時間がかかるリソースがあるので、効率化のためにやってます
僕らのリポジトリにはMockTestという、いわゆるAccTestのターゲットをMuxで立ち上げた疑似APIに向けるというものが含まれています。
このサービスって、作成開始してから完了するまで30分くらいかかるリソースも有りまして、それを毎回AccTestでリアルに作って・・・消して・・・とやっていると開発効率が悪すぎるのでMuxした感じです。
What are your thoughts on naming the provider enterprisecloud rather then ecl?
Q: Enterprise Cloud というProvider名なのにどうしてモジュール名が ecl なのですか？
A: 慣例でして・・・
本Providerでは、Resource, Datasourceのモジュール名を ecl というモジュール名にしてます。
今まで出してきた他のツール群について、以下のような形で ecl という名前にしていたのが由来なんですけどまずいですか・・・？と聞いたら特に問題ではないとのこと。
なのでそのままにしましたがごもっともなご指摘ですよね。
One of our Terraform Ecosystem engineers built a linter to help align coding best practices for providers. They use it one the AWS provider. you should use it along with your development. https://github.com/bflad/tfproviderlint
Q: https://github.com/bflad/tfproviderlint でLintしておいてね
A: かしこまりました
tfproviderlint というものが有り、それでProviderのLintができると。私は知りませんでした。やはりエコシステムが充実していますよね。
その結果を受け、関数名が規則に合っていなかった部分の修正や、それ自体のMakeターゲットを足したりする変更を実施しています。
Its required that all the providers dependancies managed using Go Modules and checked into the repo. You are already using Go Modules to manage the providers dependancies which is great, but in addition to that, we ask that you checkin all the required dependancies into a vendor/ directory. This is so that our nightly testing environment does ping GitHub for ever dependancies in all 100+ TF providers.
Q: 依存モジュールは(Go Modulesを利用していたとしても) vendor ディレクトリに入れておいてください
A: かしこまりました
多数のProviderに対して毎日テストするので、格納しておかないと大変なのでしょうね。
ということでこれも修正し、かつMakeターゲットも足しました。
Some resources are tagged v1 and other v2, but there are no overlapping names. What’s the reason for this?
Q: リソースによって(ファイル名に)v1とかv2とか混在してるけどなんで？
A: ECL自体もマイクロサービスになっていて、サービス毎に最新バージョンが違うからです
これは普通に質問でしたので回答を返して終わりです。
Attributes should be read and set on Read so that differences between the configuration and the actual state can be caught. Any non-scalar values (TypeList, TypeSet, TypeMap) should have errors checked when setting. The reasoning for this is that the provider should never panic and should error out instead.
Q: にスカラー値ではないAttributeは、ReadメソッドでState保存するときにチェックしておいてね
A: かしこまりました
これはアドバイスだったのだと思います。
親切だなぁと思いました。ありがたい。
The import path of your helper function will have to be changes from github.com/nttcom/terraform-provider-ecl/ to github.com/terraform-providers/terraform-provider-ecl/ this is because we move the repository location during the release process of this program. And will allow us to start testing the provider within our TeamCity provider test environment. I will create you an account to view the test output yourself.
Q: Provider内で自分自身を参照しているような箇所があったら、それをOrganization的に terraform-providers に変えておいてね
A: かしこまりました
Official化の処理においては、特定のコミットをupstreamにするイメージで terraform-providers org配下にこのリポジトリを持っていってくれることになるのですが、その際に困ることにならないように参照パスを変更しておいてくれということですね。
とりあえず初回のIssueはこういうものでした。
ここからチケットを切りチームで対応していってしばらくして、Issueに追加コメントが付きました。
Issue その2
その2といっても同一のIssueへのコメントのことです。
A few more items. I was able to get the go ahead on the provider name ecl. The website documentation looks great. Thanks for working on that.
Q: 名前 ecl のまま進めてください。あとドキュメントもいい感じ
A: あ・・・ありがとうございます！！
これは嬉しかったですね。
色々対応してくださっているのだろうなぁという感謝もあり。あと修正しなくて良くなったのもあり 
The acceptance test are starting to run, but I am still hitting an error. Check out the output here
Q: まだAccこけるよ？
A: すいません
色々機能追加も並行して行っていたので、その部分で問題があったり。
あとMakeターゲットの testacc って -timeout 120m とかついてたんですが、うちのAccって120分では回りきらないんですよね・・・
で、これを受けて色々変更を行いました。この修正が一番時間がかかったと思います。
というのはその次のIssueで分かることなのですが、
- CI環境は TeamCity
- 彼らは毎日テストを回している
- そのTestは
testaccをターゲットにする - 多分Test通らないとリリースされない（まぁ当然）
ということのようなのです。
しっかりとユースケースをカバーして、かつ時間内に終わる testacc ターゲットを準備することが必要であるということになります。
ということで、やったことは、概ね以下です。
- testacc-all というMakeターゲットを作って、全Accテストを回すためのターゲットを作った
- testacc-short というMakeターゲットを作って、基本的なユースケースを確認するためのテスト 以外 をSKIPする設定を入れた
- Mock Testのカバー率を拡大し、長いテストをMock化。testacc-short時はそちらを使うようにした
- testacc 自体は testacc-short を動かすためのものに変えた
- timeout時間を伸ばした
多分これでTestは時間内に通るようになったと思うので大丈夫じゃないかな・・・と踏んでます。
The makefile you have in this repository should be updated to match the standard GNUmakefile across all Terraform providers, feel free to copy the GitHub provider GNUmakefile and will just have to update the variable on line 4 to PKG_NAME=PROVIDER_NAME
Q: Makefileのファイル名は GNUMakefile にしてね。他から持ってきて、 PKG_NAME=PROVIDER_NAME に変更するのもありだよ
A: かしこまりました
実際他のOfficial Providerからファイル持ってきて、元のMakefileと同等の機能を足し込んだりしています。
Could you remove the build_and_set_provider.shscript, it wont be necessary in the new build process.
Q: build_and_set_provider.shscript に残っていたbuild系スクリプト、Official化したらもういらないだろうから消してください
A: かしこまりました
まぁ普通に削除しました。使っていないので。
ということで以上Issueその2対応でした。
が、やること多かったので結構時間がかかったんですよね。
それでもう忘れられてしまっただろうか・・・と思った頃にさらにIssueが来ました。
Issue その3
これが最後でした。それ以降はメールでのやり取りになりました。
Thanks for the work you've done to build this provider. We're ready to move on to the final phase of the program, which is to create the new repository location and trigger the first build to publish the binary at releases.hashicorp.com/ and website documentation to terraform.io
これを読んだ時 「まじか！（良い意味で)」 と思いましたね。
ついにやったぞ・・・と思うとともにうちのメンバーすごいなーと思いました。
Can you provide a list of maintainers to be added to the new repository with "write" access for future development? Please send the maintainers emails and GitHub usernames to xxxx@hashicorp.com. Whomever is added as a maintainer to the provider repository will also be granted an account on our #committers-terraform Slack channel, where you will request new versioned releases of the provider.
メンテナーの方のメールアドレスとGitHubのユーザ名をメールで送ってくれ・・・という依頼です。
これについては既に連絡済みで、現状各メンバーは冒頭で述べたリポジトリにアクセスできるようになっています。
ちなみに１０名ほど登録してもらったのですが 「１０名？多いんじゃないか？でも不可能じゃない」 と言われたのでお願いしてしまいました。
婉曲にお断りされていたかもしれませんが、無理を聞いてくださり感謝です。
また同様にそのメンバーはSlackの #committers-terraform に参加できるようです。
こちらのInviteはまだ飛んできていません。おそらくリリースのタイミングと関連があるのでしょう。とりあえず待ちです。
The follow steps and first release will be preformed by me and another HashiCorp engineer.
A repository under the same name terraform-providers-ecl will be created in the github.com/terraform-repositories/ organization.
The master will be pushed up to the new repository
今のリポジトリのmasterをベースに terraform-providers 配下にリポジトリ作るよ
A stable-website branch will be created, this is where the terraform.io provider documentation is source from. During each release, a bot will commit the changes in your master branch to the stable-website branch. If you need to make changes to the provider website docs in between releases, you can cherry-pick the commits to the stable-website branch.
stable-websiite というブランチが作られて、これが本家のドキュメントになるよ
・・・ということで冒頭に述べた通り公式サイトで既にドキュメントは見られるようになっています。
The build and release process will pull from the master branch.
The provider binary version will be tagged 1.0.0 per the CHANGELOG.md
Let me know if you have any questions.
多分ここがまだ終わっていないのですね。
1.0.0にバージョニングされるのが楽しみです。
まとめ
・・・ということでここまでどういうことをやってきたかをまとめてみました。
まだ正式に1.0.0がリリースされていませんが、順調に進むと思いますので楽しみです。
追ってコメントで記載したいと思います。
謝辞
最後に、、、
この取組にご協力下さった皆様には本当に感謝です。（執筆時点でOfficial化は終わってませんが 
お一人ずつ名前を書くのはあえて止めますが、GitHub のコミット履歴がいろいろなことを物語ってくれます。
ありがとうございます。今後とも宜しくお願いします。
正式にOfficial化終わったらここに改めて追記したいと思います。