I'd be most curious to see a working example of this idea, prefixes and all for sleeping (long term sleeping) nodes (slave and masters).
Anybody, do post what you have/are doing on this taskid resuse and reservations experimentations. Probably many are interested for a variety of reasons including but not limited to security, auditing and node diversification interests.... My interests are in self-modifying codes, which can be achieved whilst the nodes sleep for some very interesting applications.
James On 07/11/2015 06:01 AM, Adam Bordelon wrote:
Reusing taskIds may work if you're guaranteed to never be running two instances of the same taskId simultaneously, but I could imagine a particularly dangerous scenario where a master and slave experience a network partition, so the master declares the slave lost and therefore its tasks lost, and then the framework scheduler launches a new task with the same taskId. However, the task is still running on the original slave. When the slave reregisters and claims it is running that taskId, or that that taskId has completed, the Mesos master may have a difficult time reconciling which instance of the task is on which node and in which status, since it expects only one instance to exist at a time. You may be better off using a fixed taskId prefix and appending an incrementing instance/trial number so that each run gets a uniqueId. Also note that taskIds only need to be unique within a single frameworkId, so don't worry about conflicting with other frameworks. TL;DR: I wouldn't recommend it. On Fri, Jul 10, 2015 at 10:20 AM, Antonio Fernández <[email protected] <mailto:[email protected]>> wrote: Sounds risky. Every task should have its own unique id, collisions could happen and unexpected issues. I think it will be as hard to monitor that you can start again a task than get a mechanism to know it’s ID.On 10 Jul 2015, at 19:14, Jie Yu <[email protected] <mailto:[email protected]>> wrote: Re-using Task IDs is definitely not encouraged. As far as I know, many of the Mesos code assume Task ID is unique. So I probably won't risk that. On Fri, Jul 10, 2015 at 10:06 AM, Sargun Dhillon <[email protected] <mailto:[email protected]>> wrote: Is reusing Task IDs good behaviour? Let's say that I have some singleton task - I'll call it a monitoring service. It's always going to be the same process, doing the same thing, and there will only ever be one around (per instance of a framework). Reading the protobuf doc, I learned this: /** * A framework generated ID to distinguish a task. The ID must remain * unique while the task is active. However, a framework can reuse an * ID _only_ if a previous task with the same ID has reached a * terminal state (e.g., TASK_FINISHED, TASK_LOST, TASK_KILLED, etc.). */ message TaskID { required string value = 1; } --- Which makes me think that it's reasonable to just give this task the same taskID, and that every time I bring it from a terminal status to running once more, I can reuse the same ID. This also gives me the benefit of being able to more easily locate the task for a given framework, and I'm able to exploit Mesos for some weak guarantees saying there wont be multiple of these running (don't worry, they lock in Zookeeper, and concurrent runs don't do anything, they just fail). Opinions?^^Nos encantan los árboles. No me imprimas si no es necesario. Protección de Datos:Mundo Reader S.L. le informa de que los datos personales facilitados por Ud. y utilizados para el envío de esta comunicación serán objeto de tratamiento automatizado o no en nuestros ficheros, con la finalidad de gestionar la agenda de contactos de nuestra empresa y para el envío de comunicaciones profesionales por cualquier medio electrónico o no. Puede consultar en www.bq.com <http://www.bq.com/>los detalles de nuestra Política de Privacidad y dónde ejercer el derecho de acceso, rectificación, cancelación y oposición. Confidencialidad:Este mensaje contiene material confidencial y está dirigido exclusivamente a su destinatario. Cualquier revisión, modificación o distribución por otras personas, así como su reenvío sin el consentimiento expreso está estrictamente prohibido. Si usted no es el destinatario del mensaje, por favor, comuníqueselo al emisor y borre todas las copias de forma inmediata. Confidentiality:This e-mail contains material that is confidential for de sole use of de intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
