cloudfoundry-attic / bosh-notes

Collection of proposals for BOSH
Apache License 2.0
51 stars 23 forks source link

Naming of jobs, processes, deployments jobs, etc #12

Closed cppforlife closed 8 years ago

cppforlife commented 8 years ago

Initial proposal: https://github.com/cloudfoundry/bosh-notes/blob/master/deployment-naming.md

cppforlife commented 8 years ago

cc @allomov @Amit-PivotalLabs @voelzmo

allomov commented 8 years ago

I agree with you, that’s it a good field for improvement and I like this idea.

For instance it was very confusing for me at first having jobs_instances and vms in the code, since VMs can be called instances ssometimes. Understanding what's job and what's template is also not easy for newcomers, and changing things will benefit everyone.

I think that illustrating this proposal with manifest examples will let us easier catch up the idea. Here is an example I came across:

deployment: cf-with-all-you-can-imagine
director_uuid: some-hash
clusters:
- name: cf
  nodes:
  - name: uaa
    count: 2
    type: small
    jobs:
    - name: uaa
      count: 2
      processes:
        - name: uaa
          name: metron-agent
      ...
  properties:
    ...
- name: mongo-db
  nodes:
  ...
  properties:
    ...
- name: cassandra
  ...
  properties:
    ...

As far as I understood Node corresponds to a "VM type" (or warden container in case with bosh-lite) that hosts the same jobs. Jobs are such logic groups of Processes for performing some task. The processes field here is analogue for current templates field in a job item.

Could you tell me if I got the idea right?

At this moment I have following questions:

voelzmo commented 8 years ago

@cppforlife I agree that there is plenty of room for improvement on the current terms.

The term 'cluster' might actually again create some confusion. If I ask the colleagues for the redis service here, for example, then what they are doing is deploying a 'redis cluster'. However, their cluster consists of redis master nodes, redis data nodes, and probably even a sentinel load for managing the cluster.

In the new terms, their 'redis cluster' would be made of a 'redis data cluster', a 'redis master cluster', and a 'sentinel cluster'. So I fear that this might again introduce words with a different meaning than how they are already used.

If this might be an oddity on how we seem to be using the term 'cluster' I'd be happy to accept your above proposal. If others might be using 'cluster' in the same way that we do, it be a better idea to look for another term.

dpb587 commented 8 years ago

I think "cluster" is a bit too generic and confusing, like @voelzmo says. Often the collective deployment might be a colloquial cluster, with the now-termed-"jobs" running the variety of services which, only together, make the cluster. Another alternative I'd suggest is using "role" instead of "cluster".

The term "member" is mentioned in the example. That term is generic and doesn't have any connotation on its own, so seems like it might be confusing in discussions/documentation/new users. Personally I'd find "instance" a bit more descriptive in that context, and it also seems to reflect the current use of that term.

If you're asking for opinions and all :)

cppforlife commented 8 years ago

we went with instance_groups, instances and jobs to avoid massive renames and to remove duplicate names. https://github.com/cloudfoundry/bosh-notes/blob/master/finished/deployment-naming.md was updated.