Is this something that eventually worked, or is this something that completely blocked enable-ha from continuing? That looks like we're getting a failure asking MAAS about the details of "4s33ky" which seems very odd given that it is exactly the machine that we are running on. I don't see the error trace in here, but it seems like it would be part of: instId, err := m.InstanceId() if err != nil { return nil, errors.Trace(err) } interfaceInfos, err := netEnviron.NetworkInterfaces(api.callContext, instId) which ultimately leads down to: instances, err := environ.acquiredInstances(ctx, []instance.Id{instId}) if err != nil { // This path can never trigger on MAAS 2, but MAAS 2 doesn't // return an error for a machine not found, it just returns // empty results. The clause below catches that. if maasErr, ok := errors.Cause(err).(gomaasapi.ServerError); ok && maasErr.StatusCode == http.StatusNotFound { return nil, errors.NotFoundf("instance %q", instId) } return nil, errors.Annotatef(err, "getting instance %q", instId) } if len(instances) == 0 { return nil, errors.NotFoundf("instance %q", instId) } inst := instances[0] return inst, nil ... args := gomaasapi.MachinesArgs{ AgentName: environ.uuid, SystemIDs: instanceIdsToSystemIDs(ids), } ... machines, err := environ.maasController.Machines(args) And I'm guessing somewhere in there is where we are getting "not found". (You should be able to see the call stack if you used logging-config=juju.apiserver.common=TRACE on the controller model, but there is enough context in those messages that we probably know where the error is coming from. (most likely MAAS is returning an empty list when we are probing for the machine, and I don't know why that would be.) On Thu, May 24, 2018 at 12:54 PM, MichaelEino