OT:幂等，收敛，以及其他我们经常使用的愚蠢的花哨词汇

        有点 OT，但我认为许多来自某些其他工具的人可能不知道这个词的意思，并经常说它：) 我已经看到它在 bug 报告中出现相当数量，“X 不是幂等的”，等等，在 86.2% 的事件中，“幂等”这个词被错误地使用了。

        这个词的意思是一个操作是可重复的。

        在数学中，它的意思是 F(x) = F(F(x)) 就是这样。

        我们的模块都是可重复的，所以这么频繁地使用这个词并不是很有趣。

        一个更有趣的特性是，不管期望的状态如何，一个模块是否能让你达到期望的状态。

        这多少有点关系，但并不是完全相同的事情。

        这就是为什么微软将他们的配置工具命名为“期望状态配置”，而不是“幂等状态配置”(然而，尴尬的产品名称！抱歉，伙计们！)

        经典的类比是开车穿越全国。如果我想去加利福尼亚，从北卡罗来纳州向西开车就能到达那里，从提华纳向北开车就能到达那里。但你不会在你的自动化中输入“向西行驶”，因为你不确定你是从北卡罗来纳州还是墨西哥开车。 这个属性中的等幂是指，如果你再次运行“开车去加利福尼亚”，当你到达加利福尼亚时，你会停止驾驶。更重要的属性是，你能指定位置并让它带你去那里。 如果模块中有一个 bug，而你最终到了缅因州，这个 bug 不是“驾驶模块不是等幂的”。这个 bug 是“驾驶模块中有一些疯狂的混乱逻辑”。

        我认为“等幂”不知何故已经成为新的对话中的“嗯”，人们喜欢把它插入许多句子中，让事情听起来复杂。不要这样做！ 这个期望状态的东西有时也被误称为“收敛”。

        收敛通常意味着如果我运行这个过程 4 或 5 次，它就会到达我想要的地方。

        太可怕了，你想一步到位！为什么你想要一个一次只解决一半问题的模块或系统？ 不管怎样，收敛就像“开车去加利福尼亚——好吧，你在内华达州——开车去加利福尼亚——好吧，你在加利福尼亚”。不，你不希望事情收敛，你希望它按照你说的去做。

         我认为这个行业有点困扰于这样一个想法，简单的事情必须用复杂的术语来谈论，而Ansible不是那样的。

        我们的目标很简单——用简单的英语说话。把事情做好。

        因此，如果你看到我收到一封学术邮件或错误报告时有点生气，这就是原因。

        这就是我们(作为一个项目)的想法。我们希望谈论计算机，让事情变得简单，而不是更难。 是的，期望状态，等幂，我们有软件系统的这些属性。

        不过它们是无趣的属性。什么有趣？ 把工作做好！ 我想我的总体观点是，出于一些疯狂的原因，让计算机变得难以谈论是有风险的。

        计算机已经很困难了。我对世界的挑战是简单地谈论它们。

        当我们从其他配置工具吸引用户时，鼓励简单的对话。计算机已经足够复杂了。

原文：

Somewhat OT, but I think lots of people coming from certain other tools might not know what this word means, and are saying it too frequently :)  I've seen it crop up in bug reports a fair amount, "X is not idempotent", etc, and in 86.2% of the occurances, the word "idempotent" is being used incorrectly.

All this word means is an operation is repeatable.

In math, it means F(x) = F(F(x))

That's it.

Our modules all are repeatable just like that, so it's not really interesting to use that word so much.

A more interesting property is does a module get you to the desired state you want to be in regardless of the desired state.  That's somewhat related, but not quite the same thing.   This is why Microsoft named their configuration tools, quite uninterestingly, "Desired State Configuration", not "Impotent State Configuration".  (However, awkward product name!  Sorry, guys!)

The classic analogy is driving across the country.  If I want to get to California, driving west from North Carolina gets me there, driving north from Tijuana gets me there.  But you don't put "drive west" in your automation because you are not sure if you are driving from NC or Mexico.  

The idempotence in this property is that you stop driving when you get to California if you run the "drive to California" routine again.  The more important property is can you specify the location and have it get you there.

If there was a bug in a module and you ended up in Maine, the bug is not "driving module is not idempotent".  The bug is "driving module has some crazy messed up logic in it".  

I think "idempotence" has somehow become the new "um" of conversation, and folks like to insert it in many sentences to make things sound complicated.  Don't do that!  :)

This Desired State thing also gets mislabelled from time to time as "Convergence".  Convergence typically means if I run this process 4 or 5 times it gets to where I want to be.  Terrible, you want to get there in one hop!   Why do you want a module or system that only fixes half of the problem at a time?  Anyway, meh.  Convergence would be like "drive to California -- ok you are in Nevada -- drive to California - ok, you are in California".  No, you don't want stuff to converge, you want it to do what you say.

I think the industry is plagued a bit with the idea that simple things must be talked about in complicated terms, and Ansible is not like that.

Our goals are simple -- Speak in plain English.  Get stuff done.

Thus, if you see me bristle up a little bit when I get a academic email or bug report, that's why.

It's how we (as a project) think.  We want to talk about computers and make things easy, not harder.

Yes, desired state, idempotence, we have those properties of software systems.  They are uninteresting properties though.  What's interesting?  Getting work done!  

I guess my general point is there's a risk -- for some crazy reason -- to make computers hard to talk about.  Computers are already hard.  My challenge to the world is to talk about them simply.

As we attact users from other configuration tools, encourage simple dialog.  Computers are complicated enough already.

转自：https://groups.google.com/g/ansible-project/c/WpRblldA2PQ/m/lYDpFjBXDlsJ