Make AssignableVMs key on slaveId not hostname about fenzo

[spodila]

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.

import com.netflix.fenzo.plugins.VMLeaseObject;
import org.apache.mesos.Protos;

public class MyVMLeaseObject extends VMLeaseObject {

    private final String slaveId;

    public MyVMLeaseObject(Protos.Offer offer) {
        super(offer);
        this.slaveId = offer.getSlaveId().getValue();
    }

    @Override
    public String hostname() {
        return slaveId;
    }
}