Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADC17FD0-E3F0-44CC-AB34-37669B073702"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Machine Metrics
From: Geoff Macartney <geoff.macartney@cloudsoftcorp.com>
In-Reply-To: <CAEK0Ph0gAS1U+MNyPWNkf6bjdEuwq6N_OA3PDOA1_6mx9BTVmA@mail.gmail.com>
Date: Mon, 20 Jun 2016 15:52:15 +0100
Cc: dev@brooklyn.apache.org
Message-Id: <2FE14402-BCBD-49FB-96DF-6D7FA2DAFC3A@cloudsoftcorp.com>
References: <CAEK0Ph3_NVJYNwOqsGZOmRzh+EW73AaAehFb1m3TygN2Ns0jmA@mail.gmail.com> <f0e70d7a-4ec1-8a31-6647-2cf03682c39e@cloudsoftcorp.com> <D992B27C-B1A5-4495-AFDF-4CDBC5114249@cloudsoftcorp.com> <CAEK0Ph1bCQU4VSBLC3-vKvqcybBgV-+tycbv7xdgAUpq_-vffg@mail.gmail.com> <CAEK0Ph2VJLByXEPPNGTGS0sqkeMrsgSWqEM6jFaUNJK1SD1u4Q@mail.gmail.com> <60FFCB3C-C325-4330-AB6C-295A682A0F1F@cloudsoftcorp.com> <CAEK0Ph0gAS1U+MNyPWNkf6bjdEuwq6N_OA3PDOA1_6mx9BTVmA@mail.gmail.com>
To: Andrew Kennedy <andrew.kennedy@cloudsoftcorp.com>
archived-at: Mon, 20 Jun 2016 14:52:36 -0000

--Apple-Mail=_ADC17FD0-E3F0-44CC-AB34-37669B073702
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Grand thanks Andrew.

G


=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=
=94=E2=80=94=E2=80=94=E2=80=94
Gnu PGP key - http://is.gd/TTTTuI


> On 20 Jun 2016, at 15:25, Andrew Kennedy =
<andrew.kennedy@cloudsoftcorp.com> wrote:
>=20
> Geoff, I have added a `StopFeedsAtMachineTask` to the lifecycle stop =
tasks, which will take care of this. Have a look at the updated PR. =
However, as Svet pointed out, the Feed management code in Brooklyn is =
definitely in need of some attention and refactoring...
>=20
> Andrew.
>=20
> On Mon, 20 Jun 2016 at 01:41 Geoff Macartney =
<geoff.macartney@cloudsoftcorp.com =
<mailto:geoff.macartney@cloudsoftcorp.com>> wrote:
> I think that looks like a good approach, +1 from me.
>=20
> Will have a think at the feed stop problem.
>=20
> Cheers
> Geoff
>=20
>=20
> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94=E2=80=94=E2=80=94
> Gnu PGP key - http://is.gd/TTTTuI <http://is.gd/TTTTuI>
>=20
>=20
>> On 19 Jun 2016, at 15:54, Andrew Kennedy =
<andrew.kennedy@cloudsoftcorp.com =
<mailto:andrew.kennedy@cloudsoftcorp.com>> wrote:
>>=20
>> Hi.
>>=20
>> Are people happy with the initializer approach? I think the only =
outstanding issue is something @neykov pointed out, which is that when =
using `Entity#addFeed()` the feeds are not stopped when the entity is =
stopped. I will have another look at fixing that, but suggestions =
welcome.
>>=20
>> Andrew.
>>=20
>> On Thu, 16 Jun 2016 at 04:49 Andrew Kennedy =
<andrew.kennedy@cloudsoftcorp.com =
<mailto:andrew.kennedy@cloudsoftcorp.com>> wrote:
>> Thanks for the feedback.
>>=20
>> I decided on an `EntityInitializer` instead, because it also adds =
enrichers of its own. The pull request has been updated with this change =
now. To use it, add YAML like the following:
>>=20
>> ```
>> services:
>>   - type: =
org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
>>     brooklyn.initializers:
>>       - type: org.apache.brooklyn.entity.machine.AddMachineMetrics
>> ```
>>=20
>> Cheers,   =20
>> Andrew.
>>=20
>> On Thu, 16 Jun 2016 at 11:53 Geoff Macartney =
<geoff.macartney@cloudsoftcorp.com =
<mailto:geoff.macartney@cloudsoftcorp.com>> wrote:
>> I agree with Sam and Svet, + 1 to making it an enricher, if possible, =
or at least somehow keeping it separate from SoftwareProcess.
>>=20
>>=20
>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94=E2=80=94=E2=80=94
>> Gnu PGP key - http://is.gd/TTTTuI <http://is.gd/TTTTuI>
>>=20
>>=20
>>> On 16 Jun 2016, at 10:41, Sam Corbett <sam.corbett@cloudsoftcorp.com =
<mailto:sam.corbett@cloudsoftcorp.com>> wrote:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Sam
>>>=20
>>>=20
>>> On 16/06/2016 09:13, Andrew Kennedy wrote:
>>>> Hi.
>>>>=20
>>>> 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/`.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> The PR containing the change is here:
>>>>=20
>>>> - https://github.com/apache/brooklyn-server/pull/204 =
<https://github.com/apache/brooklyn-server/pull/204>
>>>>=20
>>>> I'd appreciate any comments on whether this is a useful change, as =
well as
>>>> a review of the pull request...
>>>>=20
>>>> Thanks,
>>>> Andrew.
>>>=20
>>=20
>> --=20
>> Andrew Kennedy ; Founder clocker.io <http://clocker.io/> project ; =
@grkvlt ; Cloudsoft
>>=20
>> --=20
>> Andrew Kennedy ; Founder clocker.io <http://clocker.io/> project ; =
@grkvlt ; Cloudsoft
>>=20
>=20
> --=20
> Andrew Kennedy ; Founder clocker.io <http://clocker.io/> project ; =
@grkvlt ; Cloudsoft
>=20


--Apple-Mail=_ADC17FD0-E3F0-44CC-AB34-37669B073702--