I agree with Sam and Svet, + 1 to making it an enricher, if possible, or at least somehow keeping it separate from SoftwareProcess.
———————————————————— Gnu PGP key - http://is.gd/TTTTuI > On 16 Jun 2016, at 10:41, Sam Corbett <[email protected]> wrote: > > I share your concern that the placement of the feed is wrong. I feel like we > would be bending Brooklyn's abstractions to fit the case rather than working > out a better abstraction. Of course, deciding what data reflects a software > process is subjective and as you point out we already break the encapsulation > in a variety of places. Was the plan not always to make locations into > entities too? This would be trivial if that were the case. > > I also think we're continually making SoftwareProcess too important. Svet's > suggestion of an enricher is a good one - I want to explicitly mix the > capability in to entities, not enable it with a flag. > > Sam > > > On 16/06/2016 09:13, Andrew Kennedy wrote: >> Hi. >> >> For the project I am working on, we would like to use the CPU utilization >> as one of the metrics for scaling a cluster. The existing `MachineEntity` >> has a sensor feed that produces this data, along with uptime and memory >> usage information. The feed works on Linux VMs only, currently, as is uses >> SSH commands on the host to generate the values i.e. the `uptime` command, >> or the contents of files in `/proc/`. >> >> I would like to propose moving the feed to `SoftwareProcess` so that it is >> available to all entities. It would be disabled normally, set by a >> `ConfigKey<Boolean>` flag. This would be named "metrics.machine.retrieve" >> to correspond to "metrics.usage.retrieve" which enables sensors in feeds >> that return application or process specific information. The >> `MachineEntity` would obviously have the default value set to "true", to >> maintain current behaviour. >> >> The only issue with this change is that the placement of the sensor feed >> feels slightly wrong. These are returning data about the _machine_ but the >> entity represents a _process_ on that machine, and there may in fact be >> multiple entities sharing a single machine, via `SameServerEntity`. The >> `MachineEntity` is used to represent a VM without any applications running >> on it, and would not normally be part of a blueprint, so these sensors are >> not normally accessible. There is some precedent for placing machine data >> on an entity, such as the `HOSTNAME` sensor, so I think the break in >> encapsulation is quite small. >> >> The PR containing the change is here: >> >> - https://github.com/apache/brooklyn-server/pull/204 >> >> I'd appreciate any comments on whether this is a useful change, as well as >> a review of the pull request... >> >> Thanks, >> Andrew. >
