Re: [DISCUSS] Renaming Mesos Slave
+1 no change — keep master/slave On Jun 8, 2015, at 4:17 PM, Steven Schlansker sschlans...@opentable.com wrote: On Jun 8, 2015, at 1:12 AM, Aaron Carey aca...@ilm.com wrote: I've been following this thread with interest, it draws a lot of parallels with similar problems my wife faces as a teacher (and I imagine this happens in other government/public sector organisations, earlier in this thread James pointed me to an interested Wikipedia article which suggested this also happens occasionally in software: eg County of Los Angeles in 2003). Every few years teachers are told to change the words used to describe various things related to kids with minority backgrounds, from underprivileged families or with disabilities and so on, usually to stop other children from using them as derogatory terms or insults. It works for a while and then the pupils catch on and start using the new words and the cycle repeats. I guess the point I'm trying to make here is that if you do decide to change the naming of master/slave because some naughty programmers in the community have been using the terms offensively, you better make damn sure you choose new terms which aren't likely to cause offence in the future and require the whole renaming process to run again. Which is why I'm voting for: +1 Gru/Minion Which then is great right up until Universal Pictures sues the Apache foundation to get Gru changed. Plus master/slave is immediately obvious to anyone working in software. I had to search the web to even figure out what Gru was, and then it was not even the first result... ( http://en.wikipedia.org/wiki/Main_Intelligence_Directorate_%28Russia%29 ) There could also be another option: These terms are all being used to describe a master/slave relationship, the mesos master is in charge, it assigns work to the slaves and ensures that they carry it out. I'd suggest that whatever you call this pair, the relationship will always be one of domination and servitude. Perhaps what is really needed here is to get rid of the concept of a master altogether and re-architect mesos so all nodes in the cluster are equal and reach a consensus together about work distribution and so on? I propose all processes, regardless of function, should be mesos-comrade to ensure none of them feel slighted :) From: Nikolay Borodachev [nbo...@adobe.com] Sent: 06 June 2015 04:34 To: user@mesos.apache.org Subject: RE: 答复: [DISCUSS] Renaming Mesos Slave +1 master/slave – no need to change From: Sam Salisbury [mailto:samsalisb...@gmail.com] Sent: Friday, June 05, 2015 8:31 AM To: user@mesos.apache.org Subject: Re: 答复: [DISCUSS] Renaming Mesos Slave Master/Minion +1 On 5 June 2015 at 15:14, CCAAT cc...@tampabay.rr.com wrote: +1 master/slave, no change needed. is the same as master/slaveI.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
Re: [DISCUSS] Renaming Mesos Slave
The moment it costs money for deployments to change these names, I'm +1 no change — keep master/slave. https://mail-archives.apache.org/mod_mbox/mesos-user/201506.mbox/%3c556f52ce.1050...@tampabay.rr.com%3e https://mail-archives.apache.org/mod_mbox/mesos-user/201506.mbox/%3c556f52ce.1050...@tampabay.rr.com%3E kind of summarizes it for me. On Jun 9, 2015, at 4:55 AM, Lawrence Rau larry...@mac.com wrote: +1 no change — keep master/slave On Jun 8, 2015, at 4:17 PM, Steven Schlansker sschlans...@opentable.com wrote: On Jun 8, 2015, at 1:12 AM, Aaron Carey aca...@ilm.com wrote: I've been following this thread with interest, it draws a lot of parallels with similar problems my wife faces as a teacher (and I imagine this happens in other government/public sector organisations, earlier in this thread James pointed me to an interested Wikipedia article which suggested this also happens occasionally in software: eg County of Los Angeles in 2003). Every few years teachers are told to change the words used to describe various things related to kids with minority backgrounds, from underprivileged families or with disabilities and so on, usually to stop other children from using them as derogatory terms or insults. It works for a while and then the pupils catch on and start using the new words and the cycle repeats. I guess the point I'm trying to make here is that if you do decide to change the naming of master/slave because some naughty programmers in the community have been using the terms offensively, you better make damn sure you choose new terms which aren't likely to cause offence in the future and require the whole renaming process to run again. Which is why I'm voting for: +1 Gru/Minion Which then is great right up until Universal Pictures sues the Apache foundation to get Gru changed. Plus master/slave is immediately obvious to anyone working in software. I had to search the web to even figure out what Gru was, and then it was not even the first result... ( http://en.wikipedia.org/wiki/Main_Intelligence_Directorate_%28Russia%29 ) There could also be another option: These terms are all being used to describe a master/slave relationship, the mesos master is in charge, it assigns work to the slaves and ensures that they carry it out. I'd suggest that whatever you call this pair, the relationship will always be one of domination and servitude. Perhaps what is really needed here is to get rid of the concept of a master altogether and re-architect mesos so all nodes in the cluster are equal and reach a consensus together about work distribution and so on? I propose all processes, regardless of function, should be mesos-comrade to ensure none of them feel slighted :) From: Nikolay Borodachev [nbo...@adobe.com] Sent: 06 June 2015 04:34 To: user@mesos.apache.org Subject: RE: 答复: [DISCUSS] Renaming Mesos Slave +1 master/slave – no need to change From: Sam Salisbury [mailto:samsalisb...@gmail.com] Sent: Friday, June 05, 2015 8:31 AM To: user@mesos.apache.org Subject: Re: 答复: [DISCUSS] Renaming Mesos Slave Master/Minion +1 On 5 June 2015 at 15:14, CCAAT cc...@tampabay.rr.com wrote: +1 master/slave, no change needed. is the same as master/slaveI.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
Re: [DISCUSS] Renaming Mesos Slave
On Jun 8, 2015, at 1:12 AM, Aaron Carey aca...@ilm.com wrote: I've been following this thread with interest, it draws a lot of parallels with similar problems my wife faces as a teacher (and I imagine this happens in other government/public sector organisations, earlier in this thread James pointed me to an interested Wikipedia article which suggested this also happens occasionally in software: eg County of Los Angeles in 2003). Every few years teachers are told to change the words used to describe various things related to kids with minority backgrounds, from underprivileged families or with disabilities and so on, usually to stop other children from using them as derogatory terms or insults. It works for a while and then the pupils catch on and start using the new words and the cycle repeats. I guess the point I'm trying to make here is that if you do decide to change the naming of master/slave because some naughty programmers in the community have been using the terms offensively, you better make damn sure you choose new terms which aren't likely to cause offence in the future and require the whole renaming process to run again. Which is why I'm voting for: +1 Gru/Minion Which then is great right up until Universal Pictures sues the Apache foundation to get Gru changed. Plus master/slave is immediately obvious to anyone working in software. I had to search the web to even figure out what Gru was, and then it was not even the first result... ( http://en.wikipedia.org/wiki/Main_Intelligence_Directorate_%28Russia%29 ) There could also be another option: These terms are all being used to describe a master/slave relationship, the mesos master is in charge, it assigns work to the slaves and ensures that they carry it out. I'd suggest that whatever you call this pair, the relationship will always be one of domination and servitude. Perhaps what is really needed here is to get rid of the concept of a master altogether and re-architect mesos so all nodes in the cluster are equal and reach a consensus together about work distribution and so on? I propose all processes, regardless of function, should be mesos-comrade to ensure none of them feel slighted :) From: Nikolay Borodachev [nbo...@adobe.com] Sent: 06 June 2015 04:34 To: user@mesos.apache.org Subject: RE: : [DISCUSS] Renaming Mesos Slave +1 master/slave ?C no need to change From: Sam Salisbury [mailto:samsalisb...@gmail.com] Sent: Friday, June 05, 2015 8:31 AM To: user@mesos.apache.org Subject: Re: : [DISCUSS] Renaming Mesos Slave Master/Minion +1 On 5 June 2015 at 15:14, CCAAT cc...@tampabay.rr.com wrote: +1 master/slave, no change needed. is the same as master/slaveI.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
Re: 答复: [DISCUSS] Renaming Mesos Slave
While I'm apathetic to changing the name, I think we should do more than just voting on an alternate name in case we decide to proceed and replace the master/slave terminology. Such change is very expensive and it makes sense to do it once than to rush and pick up an ambiguous term. If we make this step, we can use it as an opportunity to choose a *better* name for key Mesos components. My suggestion is to add pros and cons to every name put in for voting. Let's back up each proposal with meaningful explanation why this proposal should be preferred over others. I'll give an example (I will stick to the current terminology for clarity): * -1 for 'worker' as it implies the slave process does the actual work, which is not true and misleading. * -1 for 'leader/follower' as mesos slaves do not really *follow* the mesos master; can be confused with leading/shadowing master(s). * +1 for disambiguating between mesos slave process and mesos slave node: fwiw, multiple slave processes can be running on the same node. Some time ago we had an offline discussion about whether master and slave should actually be different entities. Having a single entity, say, mesos-agent, that can act either as slave or as master can be beneficial. Though this is outside of the scope of the current thread, I would like to keep it in mind and be as general as possible while choosing the name. Hence, my favourites so far are: 1. Mesos Node [can be disambiguated as Mesos Master Node or Mesos Agent Node] 2. Mesos Agent 3. No [Mesos Master can mean a particular mode in which a Mesos Agent currently operates] 4. Start using it in presentations, JIRAs, mailing lists, then proceed to docs update; change code via deprecation process once new terminology is settled. On Mon, Jun 8, 2015 at 10:12 AM, Aaron Carey aca...@ilm.com wrote: I've been following this thread with interest, it draws a lot of parallels with similar problems my wife faces as a teacher (and I imagine this happens in other government/public sector organisations, earlier in this thread James pointed me to an interested Wikipedia article which suggested this also happens occasionally in software: eg County of Los Angeles in 2003). Every few years teachers are told to change the words used to describe various things related to kids with minority backgrounds, from underprivileged families or with disabilities and so on, usually to stop other children from using them as derogatory terms or insults. It works for a while and then the pupils catch on and start using the new words and the cycle repeats. I guess the point I'm trying to make here is that if you do decide to change the naming of master/slave because some naughty programmers in the community have been using the terms offensively, you better make damn sure you choose new terms which aren't likely to cause offence in the future and require the whole renaming process to run again. Which is why I'm voting for: +1 Gru/Minion There could also be another option: These terms are all being used to describe a master/slave relationship, the mesos master is in charge, it assigns work to the slaves and ensures that they carry it out. I'd suggest that whatever you call this pair, the relationship will always be one of domination and servitude. Perhaps what is really needed here is to get rid of the concept of a master altogether and re-architect mesos so all nodes in the cluster are equal and reach a consensus together about work distribution and so on? -- *From:* Nikolay Borodachev [nbo...@adobe.com] *Sent:* 06 June 2015 04:34 *To:* user@mesos.apache.org *Subject:* RE: 答复: [DISCUSS] Renaming Mesos Slave +1 master/slave – no need to change *From:* Sam Salisbury [mailto:samsalisb...@gmail.com] *Sent:* Friday, June 05, 2015 8:31 AM *To:* user@mesos.apache.org *Subject:* Re: 答复: [DISCUSS] Renaming Mesos Slave Master/Minion +1 On 5 June 2015 at 15:14, CCAAT cc...@tampabay.rr.com wrote: +1 master/slave, no change needed. is the same as master/slaveI.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
Re: Can Mesos master offer resources to multiple frameworks simultaneously?
Hi Michael, I think it may not be the latter becauseI see this in the comments of the function resourceOffers(): * Note that resources may be concurrently offered to more than one * framework at a time (depending on the allocator being used). In * that case, the first framework to launch tasks using those * resources will be able to use them while the other frameworks * will have those resources rescinded (or if a framework has * already launched tasks with those resources then those tasks will * fail with a TASK_LOST status and a message saying as much). */ So Mesos can support both 1 and 2 which actually depends on which allocator being used, right? 2015-06-06 19:06 GMT+08:00 Michael Hausenblas michael.hausenb...@gmail.com : 1. Mesos master offers all the resources to all the frameworks simultaneously. 2. Mesos master offers resources to one framework at a time, e.g., it offers r1, r2, r3 to f1, and f1 accepts r1, and then it offers r2 and r3 to f2, ... The latter, yes. For a quick overview, I suggest you have a look at http://mesos.apache.org/documentation/latest/mesos-architecture/ which covers the resource offer cycle. If you want to dive deeper, you might want to read: 1. http://mesos.berkeley.edu/mesos_tech_report.pdf 2. https://www.cs.berkeley.edu/~alig/papers/drf.pdf Note that there's a feature in the works that would be closer to your 1., see https://issues.apache.org/jira/browse/MESOS-1607 Cheers, Michael -- Michael Hausenblas Ireland, Europe http://mhausenblas.info/ On 6 Jun 2015, at 12:51, Qian Zhang zhq527...@gmail.com wrote: Hi, I am new to Mesos, and I'd like to know if there are a lot resources in the Mesos cluster, how will Mesos master offer these resources to the multiple frameworks? I guess there can be two ways: 1. Mesos master offers all the resources to all the frameworks simultaneously. 2. Mesos master offers resources to one framework at a time, e.g., it offers r1, r2, r3 to f1, and f1 accepts r1, and then it offers r2 and r3 to f2, ... If it is 1, then I'd like to know how Mesos master resolves the conflicts, e.g., multiple frameworks accept the same resource. If it is 2, then I see it is actually a serial process since Mesos master handle the frameworks one by one, then what is advantage of Mesos against traditional monolithic resource scheduler? Thanks, Qian
