On 06/02/2015 11:30 AM, Alexander Gallego wrote:
1. mesos-worker
2. mesos-worker
Currently, my (limited) understanding of the codebase for mesos, is that
slave does not have any autonomy, is 100% controlled by the Master,
hence the clear nomenclature of Master-Slave. If we are to migrate to
'mesos-worker' this implies that the worker has 'some standing' some
rights? The worker can leave the mesos and move on (attach) to another
supervisor? Actually I like this concept, since mesos is not likely to
be the only "master" in a data center, maybe we need to begin thinking
about node (migration) to other "masters" in a heterogeneous data-center
? Ah! Eureka now I see what is really going on; mesos leadership is
preparing for other "masters" to migrate node-worker hardware to other
cluster codes, in the spirit of heterogeneous, politically_correct,
cluster compuations? I see, we would not want to offend any other
software development team; after all
opensource is opensource......
Also, what happens to mesos clustering codes if folks decided to
experiment with self modifying codes; like the code found in stuxnet?
Are those still worker codes? Are they subservient to the "mesos"
after they are instantiated? We have the family of self-modifying codes
to contend with in the future; surely they are going to find a path
to these clusters, whether the developers like it or not.
How shall the naming classifications match reality in the future? I'd
suggest some thought as to where mesos is heading, as changes in
nomenclature and diversions, no matter how well-intended, from
established jargon can cause loads of unforeseen problems if not lead to
obscurity. For example when somebody has work in a multi-processor
hardware development group, you either have master-slave relationships,
voter, or some non-sensical, if not exotic, nomenclature that does not
withstand the ravages of competing codes over time. A historical review
might be in order for parallel efforts; look at how divergent naming
schemes have not survived...... I doubt seriously this is the first
venture into finding a more accurate and alternative naming scheme. A
less accurate scheme; surely many exist, as we've seen a few in this thread.
Change the names as you like. But, but be mindful that your new
nomenclature is sensical and exudes forethought of the futuristic
feature sets to be found in parallel processing, both hardware and software.
hth,
James
