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

[Viet Nguyen]

Heiko,

OpenShift source-to-image (S2I) does what you just describe.  The DeploymentConfig ('app' config or cattle breeder if you will) remains static. 

Very likely that in a production OpenShift setup there will be a persistent storage for the WF instance.  So regardless of where the WF pod has lived we can still identify its former self. No?


Viet

----- Original Message -----
From: "Heiko W.Rupp" <hrupp at redhat.com>
To: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
Cc: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Thursday, July 28, 2016 7:20:59 AM
Subject: Re: [Hawkular-dev] Identification of WildFly in container in a Kube/Openshift env

On 27 Jul 2016, at 17:02, Juraci Paixão Kröhling wrote:

> 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

There is one case we need to consider here:

we have an image with foobar.war;v1 with a certain sha.
Now the user creates a new image with foobar.war;v2.
For the user this is logically the same thing but with a
different version.
We should not treat that as different applications.
In this case we would rather need to record the fact
that v1 was replaced by v2 (by putting a tag) and
continue the already recorded metrics for the same
(logical) application.

_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev