[solved][naming] alternatives to 'spit', 'rub', 'polish'

[bernard357]

As a matter of fact, names do matter in software, because of the meanings that they convey. When plumbery was created initially, we had the analogy of a plumber doing practical things in phases. This poorly explain some terms that were selected at that time:

• 'spit' - this is called after initial build of domains, networks and nodes, in order to handle network addresses, security rules, addition of disks, automatic monitoring, etc. Everything you can do from MCP perspective, and that do not require nodes to be up and running
• 'rub' - this is where you connect to nodes via ssh to contextualize them one by one
• 'polish' - this is an extension mechanism where each node is provided to a polisher in sequence.

This terminology is consistent if you think about a real worker building fittings in sequence. Rubbing is coming from the Aladdin story, where the lamp is rubbed to make the genius appear. Spitting is common practice before rubbing, my grandmother was doing that...

However, now that plumbery is moving to new levels of ambitions, there is a need to introduce new terms, that can make sense to larger sets of people. Some suggestions:

• 'walk' instead of 'polish' - again, we are talking of an extension mechanism, that is not limited to fittings finalization. For example, you could design a 'freemind' polisher to generate a mindmap file out of some fittings plan. In the terminology, 'walker' would be used instead of 'polisher'. An other idea would be 'inspect', to reflect the fact that the extension module is given the chance to inspect every node.
• 'ignite' instead of 'rub' - this is where life is brought to each node. After ignition, nodes are up and running. The term 'prepare' does not convey the same idea. If 'ignite' is not appropriate, maybe 'contextualise' could do the job, or 'finalize'.
• 'prepare' instead of 'spit' - this is phase 2 of build actions. It is related to every configuration that can be done before nodes are starting: network, security, disks, monitoring, ...

Again, terms do matter, and there is a need for some consensus before moving forward. Happy to have quick review of other suggestions before code and documentation are changed at large.

[tonybaloney]

The names are really important as they aid the user to understand the terminology of the product and how that relates to the actions . Especially when it comes to processes, I find it sensible to first explain to the user the process (or even better, not have to).

If you have to explain it too many times it's either too complex or too confusing.

What I am trying to do in my mind when I review these terms is to picture and visualise the infrastructure at each stage through the process.

• Which stages does the user need to be aware of?
• Which stages should the user have control over?

If we go back to the process

1) The network is laid down 2) The servers are deployed 3) The post-checks are carried out 4) Complete the networking configuration 5) Configure the nodes 6) Run extensible "plugins" on the nodes

Let's focus on describing those stages, as, they may change, expand or be configurable in future.

My super-boring literal translation is

1) deploy-network 2) deploy-nodes 3) validate 4) configure-network 5) configure-nodes 6) post-configuration

If I said what does "deploy-nodes" do to a beginner, it's pretty self-explanatory.

[bernard357]

Anthony, your view is making a lot of sense in the context of a service deployment. The actual steps managed by plumbery in such case are close to what you mentioned: 1) build (domains, networks, and nodes) 2) configure (ex-spit) = add network addresses, firewall rules and everything that do not need running nodes 3) start (nodes) 4) prepare (ex-rub) the nodes 5) information - to drive next steps of usage

These 5 steps can be handled as a single action with 'deploy'

There are also other use cases, typically, situations where you want to use deployment information for some reason. Some examples :

• ansible - create inventory information, including groups, to be used by ansible on deployed nodes
• stop / start - to save on costs when a demo deployment is not used
• ping - to check status and network information for each nodes