You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 31, 2023. It is now read-only.
Hostname appears to be informational to Mesos: hostname does not appear in TaskStatus messages or TaskInfo messages. SlaveID does, and for Mesos tasks are assigned by SlaveID, not by hostname. This means that a framework that uses Fenzo must map SlaveIDs to hostnames just so that it can call Fenzo when a task state changes.
Better yet, make the taskUnassigner take a TaskStatus and then just pull out whatever is required.
The text was updated successfully, but these errors were encountered:
The "SlaveID" value is more ephemeral than the "hostname" field. That is, there could be multiple "slaveId" values for the same physical host, for example when the mesos agent times out its pings and then later reconnects with the master. OTOH, a new host could take on the same hostname as one that was decommissioned before. In practice this is less frequent than changes to slaveId of the same host.
This also affects other aspects in the system. For example, cluster autoscaling. If a new slaveId is treated as a new host, a scale down can trigger on the old slaveId since it does not have any running tasks. The scaling actions implementation you provide will have to remember the slaveId values used for a host name, or use some other similar technique to ensure scale down does not terminate a host that is running tasks with a different slaveId at the moment.
Additional thoughts welcome.
To offer a workaround/hack for you: If your framework does not need to use the cluster autoscaling feature (now or in the future), it is likely that you could always use the slaveId as the hostname when interfacing with Fenzo. That is, you will pass the offer's slaveId as the hostname. From then on, you can use slaveid as the hostname for calls to the taskUnassigner and taskAssigner, for example. I have not tested this though.
For this hack, you will need to use a VMLeaseObject that returns slaveId when asked for hostname. You can use the following sample object to wrap the offers that are input into Fenzo.
Hostname appears to be informational to Mesos: hostname does not appear in TaskStatus messages or TaskInfo messages. SlaveID does, and for Mesos tasks are assigned by SlaveID, not by hostname. This means that a framework that uses Fenzo must map SlaveIDs to hostnames just so that it can call Fenzo when a task state changes.
Better yet, make the taskUnassigner take a TaskStatus and then just pull out whatever is required.
The text was updated successfully, but these errors were encountered: