f72e599ee7
This change makes few compromises: * Looks up the devices associated with tasks at look up time. Given that `nomad alloc status` is called rarely generally (compared to stats telemetry and general job reporting), it seems fine. However, the lookup overhead grows bounded by number of `tasks x total-host-devices`, which can be significant. * `client.Client` performs the task devices->statistics lookup. It passes self to alloc/task runners so they can look up the device statistics allocated to them. * Currently alloc/task runners are responsible for constructing the entire RPC response for stats * The alternatives for making task runners device statistics aware don't seem appealing (e.g. having task runners contain reference to hostStats) * On the alloc aggregation resource usage, I did a naive merging of task device statistics. * Personally, I question the value of such aggregation, compared to costs of struct duplication and bloating the response - but opted to be consistent in the API. * With naive concatination, device instances from a single device group used by separate tasks in the alloc, would be aggregated in two separate device group statistics.
24 lines
679 B
Go
24 lines
679 B
Go
package interfaces
|
|
|
|
import (
|
|
"github.com/hashicorp/nomad/nomad/structs"
|
|
"github.com/hashicorp/nomad/plugins/device"
|
|
)
|
|
|
|
type Client interface {
|
|
AllocStateHandler
|
|
}
|
|
|
|
// AllocStateHandler exposes a handler to be called when a allocation's state changes
|
|
type AllocStateHandler interface {
|
|
// AllocStateUpdated is used to emit an updated allocation. This allocation
|
|
// is stripped to only include client settable fields.
|
|
AllocStateUpdated(alloc *structs.Allocation)
|
|
}
|
|
|
|
// DeviceStatsReporter gives access to the latest resource usage
|
|
// for devices
|
|
type DeviceStatsReporter interface {
|
|
LatestDeviceResourceStats([]*structs.AllocatedDeviceResource) []*device.DeviceGroupStats
|
|
}
|