2013年5月16日

serverspec v0.3.2 以降について

matcherの名前など、今後についての議論まとめ 続きはIssue104で! https://github.com/mizzy/serverspec/issues/104
0
tagomoris @tagomoris

server specのDSLをまとまった量はじめて見たけど、これは、んー。be_enabled だけ見て service コマンドの結果(だよね?)だとわかれというの大分難易度高い。

2013-05-16 13:25:28
tagomoris @tagomoris

describe セクションみたいな感じでどの領域のテストなのかを宣言できれば matcher のセットを切り替えられるし、そういう機能あったほうがよさそうな気がする

2013-05-16 13:25:59
tagomoris @tagomoris

@kentaro serverspec users are only ether chef users or puppet users?

2013-05-16 13:39:51
栗林健太郎 @kentaro

@tagomoris Of course, no. I meant the fact was natural for them. Any ided for better vocabulary?

2013-05-16 13:42:41
mizzy @gosukenator

@tagomoris そうなんですよねー。かといって、be_enabled_as_service とかも冗長かなー、と思い、とりあえずはbe_enabledにしています。セクションの件、検討してみますね。

2013-05-16 13:47:14
tagomoris @tagomoris

@gosukenator rspecと違ってマッチしないといけない対象のバリエーションが多過ぎるので名前空間全体でmatcher名を共有しちゃうとつらい(し、あまり意味がない)気がしますね。セクションで切り替えられるとmatcher名にあまり悩まなくてよくなりそうです。

2013-05-16 13:48:38
mizzy @gosukenator

@tagomoris そうですね。マッチャ名を冗長にして判別しやすくするか、ダブっても内部でいい具合に処理することで短く書けるようにするのがいいのか、どちらがいいかは自分の中でまだ決め兼ねている感じです。マッチャ増えてきたので、そろそろ方針決めた方が良さそうですね。

2013-05-16 13:54:01
fujiwara @fujiwara

be_enabledがserviceに掛かるのか、たとえばSELinuxに掛かるのかその他なにか有効化されうるものなのか、がこれからmatcherどんどん増えていくと判断しにくくなる感じはしている #serverspec

2013-05-16 13:41:42
fujiwara @fujiwara

describe 'service[httpd]' みたいに書ければいいのだろうか

2013-05-16 13:44:44
fujiwara @fujiwara

Chefの場合は先に service "httpd" … で対象のスコープが分かれるから、その中で名前が被っても問題は感じないんだけど

2013-05-16 13:52:22
tagomoris @tagomoris

まさにこれを社内で言ってた RT @fujiwara: be_enabledがserviceに掛かるのか、たとえばSELinuxに掛かるのかその他なにか有効化されうるものなのか、がこれからmatcherどんどん増えていくと判断しにくくなる感じはしている #serverspec

2013-05-16 13:49:09
mizzy @gosukenator

@fujiwara 今のところまだ大丈夫なので、そうなった時に対応考えよう、と思っています。

2013-05-16 13:48:36
fujiwara @fujiwara

@gosukenator そうですね、SELinuxの時に名前ぶつかりそうでどうしたものかな、とはちょっと思ったので、今後増えていってドキュメント一覧できないぐらいになったら何かほしい感じですね

2013-05-16 13:50:51
mizzy @gosukenator

@fujiwara ですねー。そろそろ考えたほうが良さそうですね。service[httpd]の案、参考にさせていただきますー

2013-05-16 13:56:09
fujiwara @fujiwara

@gosukenator 'service[httpd]'の文字列parseするのも微妙な感じはしています!

2013-05-16 13:57:34
栗林健太郎 @kentaro

Can we change the `self` of `be_enabled` along with the context?

2013-05-16 13:56:53
mizzy @gosukenator

#serverspec について、最初は冗長な方が良いかな(例: have_iptables_rule) と思っていたけど、最近はシンプルにして subject に来るもので判断するのがいいのかな、という方向に傾いてるものの、(つづく)

2013-05-16 14:15:33
mizzy @gosukenator

#serverspec 同じマッチャが違う種類の対象にも使える、というのは混乱しそうだよなー、とは思っていたので、モリスさんのセクションとか、組長のprefixのように、頭に何かつけて判別、というのはいい落としどころのような気がします。(PuppetやChefもそうだし)

2013-05-16 14:17:20
mizzy @gosukenator

RSpec の枠内でやるならこんな感じ? describe 'service' do context 'httpd' do it { should be_enabled } end end

2013-05-16 14:20:48
mizzy @gosukenator

RSpec からは外れるけど、こんな感じとか。 service 'httpd' do it { should be_enabled } end

2013-05-16 14:23:56
Tatsuya Takamura @tkmr

@gosukenator service('httpd') が enabled? メソッドに反応するオブジェクトを返せば、下記でもいけそうですね。 describe service('httpd') do it { should be_enabled } end

2013-05-16 14:41:13
tagomoris @tagomoris

@gosukenator 他の案としては subject のブロック内で使う主体の切り替え用の命令とか?

2013-05-16 14:30:16
mizzy @gosukenator

@tagomoris イシュー立てたので具体的にどんな記述になるのかを書いてもらえると、大変うれしいです! https://t.co/aimdhTVuGV

2013-05-16 14:40:46
mizzy @gosukenator

be_enabled.rbとかhave_entry.rbとかの中でsubjectのtypeを判断させる、という方向で考えいて、ただ、if とかcaseとかで分岐するのもいけてないなー、と思ってたけど、@tkmr さんのアイデアならこれをきれいに解決できるなー。グレートだ。

2013-05-16 14:52:43

コメント

コメントがまだありません。感想を最初に伝えてみませんか?