+1 to what Adam wrote. 1. Mesos Worker [Node] 2. Mesos Worker or Agent 3. No 4. Carefully
On Fri, Jun 5, 2015 at 6:31 AM, Sam Salisbury <[email protected]> wrote: > Master/Minion +1 > > On 5 June 2015 at 15:14, CCAAT <[email protected]> wrote: > >> >> "+1 master/slave, no change needed." is the same as >> "master/slave" I.E. keep the nomenclature as it currently is >> >> This means keep the name 'master' and keep the name 'slave'. >> >> >> Are you applying fuzzy math or kalman filters to your summations below? >> >> It looks to me, tallying things up, Master is kept as it is >> and 'Slave' is kept as it is. There did not seem to be any consensus >> on the new names if the pair names are updated. Or you can vote >> separately on each name? On an real ballot, you enter the choices, >> vote according to your needs, tally the results and publish them. >> Applying a 'fuzzy filter' to what has occurred in this debate so far >> is ridiculous. >> >> Why not repost the question like this or something on a more fair >> voting preference: >> >> ----------------> >> Please vote for your favourite Name-pair in Mesos, for what is currently >> "Master-Slave". Note Master-Slave is the "no change" vote option. >> >> [] Master-Slave >> [] Mesos-Slave >> [] Mesos-Minion >> [] Master-Minion >> [] Master-Follower >> [] Mesos-Follower >> [] Master-worker >> [] Mesos-worker >> [] etc etc >> >> <----------------- >> >> >> Tally the result and go from there. >> James >> >> >> >> >> On 06/05/2015 04:27 AM, Adam Bordelon wrote: >> >>> Wow, what a response! Allow me to attempt to summarize the sentiment so >>> far. >>> >>> Let's start with the implicit question, >>> _0. Should we rename Mesos Slave?_ >>> +1 (Explicit approval) 12, including 7 from JIRA >>> +0.5 (Implicit approval, suggested alternate name) 18 >>> -0.5 (Some disapproval, wouldn't block it) 5, including 1 from JIRA >>> -1 (Strong disapproval) 16 >>> >>> _1. What should we call the "Mesos Slave" node/host/machine?_ >>> Worker: +10, -2 >>> Agent: +6 >>> Follower (+Leader): +4, -1 >>> Minion: +2, -1 >>> Drone (+Director/Queen): +2 >>> Resource-Agent/Provider: +2 >>> >>> _2. What should we call the "mesos-slave" process (could be the same)?_ >>> Pretty much everybody says that it should be the same as the node. >>> >>> _3. Do we need to rename Mesos Master too?_ >>> Most say No, except when slave's new name has a preferred pairing (e.g. >>> Follower/Leader) >>> >>> _4. How will we phase in the new name and phase out the old name?_ >>> To calm any fears, we would have to go through a full deprecation cycle, >>> introducing the new name in one release, while maintaining >>> symlinks/aliases/duplicate-endpoints for the old name. In a subsequent >>> release, we can remove the old name/endpoints. As we introduce the new >>> Mesos 1.0 HTTP API, we will already be introducing breaking API changes, >>> so this would be an ideal time to do a rename. >>> >>> Whether or not we decide to officially change the name in the code/APIs, >>> some organizations are already using alternative terminologies in their >>> presentations/scripts. We could at least try to agree upon a recommended >>> alternative name for these purposes. >>> >>> _5. How do we vote on this?_ >>> First, FYI: https://www.apache.org/foundation/voting.html >>> It seems there are two potentially separate items to vote on: >>> >>> Prop-A: Rename Mesos-Slave in the code/APIs >>> Qualifies as a "code modification", so a negative (binding) vote >>> constitutes a veto. Note that there are no -1s from the Mesos PMC yet. >>> After this week of discussion where the community is invited to share >>> their thoughts/opinions, we will call for an official VOTE from the PMC >>> members. The proposal will pass if there are at least three positive >>> votes and no negative ones. >>> >>> Prop-B: Recommended Alternative Name for "Slave" >>> This can follow the common format of majority rule. We can gather >>> recommendations during this one week discussion period, and then vote on >>> the top 2-3 finalists. >>> >>> On Thu, Jun 4, 2015 at 8:23 PM, Emilien Kenler <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> +1 for keeping master/slave. >>> >>> On Fri, Jun 5, 2015 at 12:00 PM, Panyungao (Wingoal) >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> +1 master/slave. ____ >>> >>> __ __ >>> >>> These are only terminologies in software architecture. They >>> have different definitions from those of social or political >>> view. ____ >>> >>> __ __ >>> >>> *发件人:*zhou weitao [mailto:[email protected] >>> <mailto:[email protected]>] >>> *发送时间:*2015年6月5日10:40 >>> *收件人:*[email protected] <mailto:[email protected]> >>> *主题:*Re: [DISCUSS] Renaming Mesos Slave____ >>> >>> __ __ >>> >>> +1 master/slave, no change needed.____ >>> >>> __ __ >>> >>> 2015-06-05 0:10 GMT+08:00 Ankur Chauhan <[email protected] >>> <mailto:[email protected]>>:____ >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> +1 master/slave >>> >>> James made some very good points and there is no technical >>> reason for >>> wasting time on this. >>> >>> On 04/06/2015 08:45, James Vanns wrote: >>> > +1 master/slave, no change needed. >>> > >>> > I couldn't agree more. This is a barmy request; master/slave >>> is a >>> > well understood common convention (if it isn't well defined). >>> This >>> > is making an issue out of something that isn't. Not at least >>> as far >>> > as I see it - I don't have a habit of confusing >>> software/systems >>> > nomenclature with moral high ground. This would just be a >>> waste of >>> > time and not just for developers but for those adopting/who >>> have >>> > adopted Mesos. If it were a brand new project at the early >>> stages >>> > of just throwing ideas around, then fine - call master/slave >>> > whatever you want. Gru/Minion would get my vote if that were >>> the >>> > case ;) >>> > >>> > Cheers, >>> > >>> > Jim >>> > >>> > >>> > On 4 June 2015 at 16:23, Eren Güven <[email protected] >>> <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>> >>> wrote: >>> > >>> > +1 master/slave, no change needed >>> > >>> > Such a change is a waste of time with no technical benefit. >>> Also >>> > agree with Itamar, a breaking change like this will cause >>> upgrade >>> > pains. >>> > >>> > Cheers >>> > >>> > On 4 June 2015 at 17:08, tommy xiao <[email protected] <mailto: >>> [email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> > >>> > +1 to James DeFelice. I don't feel the name is confuse for any >>> > circumstance. >>> > >>> > 2015-06-04 22:06 GMT+08:00 James DeFelice < >>> [email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto: >>> [email protected]>>>: >>> > >>> > -1 master/worker -1 master/agent -1 leader/follower >>> > >>> > +1 master/slave; no change needed >>> > >>> > There's no technical benefit **at all** to a terminology >>> change at >>> > this point. If people want to change the names in their client >>> > presentations that's fine. Master/slave conveys specific >>> meaning >>> > that is lost otherwise. In this context of this project (and >>> > elsewhere in Engineering-related fields) the terms are >>> technical >>> > jargon and have no social implications within such context. >>> > >>> > >>> > On Thu, Jun 4, 2015 at 9:53 AM, Till Toenshoff < >>> [email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> > >>> >> 1. Mesos Worker [node/host/machine] 2. Mesos Worker [process] >>> 3. >>> >> No, master/worker seems to address the issue with less >>> changes. >>> >> 4. Begin using the new name ASAP, add a disambiguation to the >>> >> docs, and change old references over time. Fixing the >>> "official" >>> >> name, even before changes are in place, would be a good first >>> >> step. >>> > >>> > +1 >>> > >>> > >>> > >>> > >>> > -- James DeFelice585.241.9488 <tel:585.241.9488> <tel: >>> 585.241.9488 >>> <tel:585.241.9488>> (voice) >>> >650.649.6071 <tel:650.649.6071> <tel:650.649.6071 >>> <tel:650.649.6071>> (fax) >>> > >>> > >>> > >>> > >>> > -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com < >>> http://gmail.com> >>> > <http://gmail.com> >>> > >>> > >>> > >>> > >>> > >>> > -- -- Senior Code Pig Industrial Light & Magic >>> -----BEGIN PGP SIGNATURE----- >>> >>> iQEcBAEBAgAGBQJVcHhwAAoJEOSJAMhvLp3L8E4H/2ug5bAs5S7sZrGVZyp4vdki >>> tEd67eQDu1gXCV1fC6VqStnlGG9UHG95/RaCkiLLEmtbYBIY4f+6Urbwoo0P4Qyh >>> sU4Z0y3cdXkibH1DTIwT3tRXa/yp9Msx+KAI6NqXvfOtnLVXXtT4nKD9BCQ/+u98 >>> afvICT1z25lBiYjBaZaVlrJRFtZkmRzVhwWiSnmtfyBfyvwbg8tEGoR1mqf3h7D5 >>> ZpxTUvjLc1sF0NNLFTt30ReJfynOGY0tNfozi9Ubf5Hs7/3xfuHSBDVDm1+2EP4/ >>> cHEMs2S0+54JsgSTGBGq4PGL/nKQ8vuwjzVihgQXpA3CU8QBikuvdRc/UBwDaR0= >>> =niNh >>> -----END PGP SIGNATURE-----____ >>> >>> __ __ >>> >>> >>> >>> >>> -- >>> <http://www.wizcorp.jp/> Emilien Kenler >>> Server Engineer | Wizcorp Inc. <http://www.wizcorp.jp/> >>> >>> ------------------------------------------------------------------------ >>> TECH . GAMING . OPEN-SOURCE WIZARDS >>> + 81 (0)3-4550-1448|Website <http://www.wizcorp.jp/>|Twitter >>> <https://twitter.com/Wizcorp>|Facebook >>> <http://www.facebook.com/Wizcorp>|LinkedIn >>> <http://www.linkedin.com/company/wizcorp> >>> >>> >>> >> >
