[Hawkular-dev] Identification of WildFly in container in a Kube/Openshift env

[Juraci Paixão Kröhling]

On 27.07.2016 13:41, Heiko W.Rupp wrote:
> On 22 Jul 2016, at 17:58, Juraci Paixão Kröhling wrote:
>
>> Do we still see the main monitored subject as the application, or do we
>> care about the OS/environment? In other words: does it make sense to
>> have two application instances with the same feed-id? If so, having
>
> I am not sure I understood the question.

IIRC, at the beginning of Hawkular, the main idea was to have metrics on 
a per-application basis, instead of a per-deployment/instance. The OS 
metrics were an "extra". So, the question is if we still have a focus on 
the "per application metrics", no matter how many instances (containers, 
VMs, ...) are there for this application. Or if we still need the OS 
metrics, even for container environments. If we need the OS metrics, 
then we need one feed-id per "application" instance.

> Right now the feed-id more or less "identifies the agent". In a case where
> one WildFly has one embedded agent, the feed-id more or less also
> identifies that server (at least in standalone mode; I don't think Domain+
> Docker/K8s makes too much sense, as you now would have 2 competing
> orchestration systems, but I may be wrong).
> Now what is an "application instance". If it is a WF running a certain .?ar
> file, I don't think it does not make sense to have two with the same
> feed-id with this current model I described.

Right, that's my point. For an infra where the application is deployed 
on Docker containers, like in OpenShift, it doesn't matter to Hawkular 
how many containers are there for a given application: Openshift would 
auto scale up and down on demand. In such scenario, the feed-id isn't of 
much help, as it would change very often.

>> an
>> alternate algorithm for containers that comes up with an ID based on
>> local artifacts would solve most of the issues, I believe.
>
> Can you describe that please?

Sure: if we assume that the feed-id for an image should remain the same 
for all instances of that image (I'm not sure yet that's the case), then 
the alternative algorithm could be used when the Agent starts, based on 
the checksum for the content of the artifacts found on 
standalone/deployments . Example:

- standalone/deployments/foobar.war
sha1sum: 96866e09c9ade125d9f3d3fc9766ccba5961968e

- standalone/deployments/foobar-ds.xml
sha1sum: 644faffab30df784c995fa75e4ff84bcf0857d6e

- feed-id: sha1sum(sha1sum(foobar.war) + sha1sum(foobar-ds.xml))
result: a4f36be49f641967e51e2707c1fe6d0a29c2f682

If there's a new image for the foobar-service, there are two possible 
scenarios:

- Only the underlying artifacts were changed (OS updates, EAP updates, 
...), but the foobar-service itself is the same. On this scenario, the 
resulting sha1sum is the same, so, the same feed-id as before is used.

- foobar-service has changed, no matter if the OS was updated or not: 
the sha1sum is new, so, new feed-id.

For non-container deployments, the feed-id could still be generated the 
way it is today. A new configuration parameter on standalone.xml would 
make sense, on this case, to specify the feed-id algo to use.

- Juca.