Re: [Hawkular-dev] Identification of WildFly in container in a Kube/Openshift env
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(a)redhat.com>
To: "Juraci Paixão Kröhling" <jpkroehling(a)redhat.com>
Cc: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev