{"action":"opened","issue":{"url":"https://api.github.com/repos/DimensionDataCBUSydney/plumbery/issues/15","repository_url":"https://api.github.com/repos/DimensionDataCBUSydney/plumbery","labels_url":"https://api.github.com/repos/DimensionDataCBUSydney/plumbery/issues/15/labels{/name}","comments_url":"https://api.github.com/repos/DimensionDataCBUSydney/plumbery/issues/15/comments","events_url":"https://api.github.com/repos/DimensionDataCBUSydney/plumbery/issues/15/events","html_url":"https://github.com/DimensionDataCBUSydney/plumbery/issues/15","id":140909690,"number":15,"title":"[naming] alternatives to 'spit', 'rub', 'polish'","user":{"login":"bernard357","id":235078,"avatar_url":"https://avatars.githubusercontent.com/u/235078?v=3","gravatar_id":"","url":"https://api.github.com/users/bernard357","html_url":"https://github.com/bernard357","followers_url":"https://api.github.com/users/bernard357/followers","following_url":"https://api.github.com/users/bernard357/following{/other_user}","gists_url":"https://api.github.com/users/bernard357/gists{/gist_id}","starred_url":"https://api.github.com/users/bernard357/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bernard357/subscriptions","organizations_url":"https://api.github.com/users/bernard357/orgs","repos_url":"https://api.github.com/users/bernard357/repos","events_url":"https://api.github.com/users/bernard357/events{/privacy}","received_events_url":"https://api.github.com/users/bernard357/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-03-15T08:46:19Z","updated_at":"2016-03-15T08:46:19Z","closed_at":null,"body":"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:\r\n\r\n- '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\r\n\r\n- 'rub' - this is where you connect to nodes via ssh to contextualize them one by one\r\n\r\n-'polish' - this is an extension mechanism where each node is provided to a polisher in sequence.\r\n\r\nThis 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...\r\n\r\nHowever, 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:\r\n\r\n- '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.\r\n\r\n- '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'.\r\n\r\n- '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, ... \r\n\r\nAgain, 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.\r\n\r\n"}}