3:04 p.m.
On 9/15/2015 3:12 PM, Heiko W.Rupp wrote:
On 15 Sep 2015, at 19:52, Jay Shaughnessy wrote:
> No. I think data should just live on until some TTL perhaps kicks in.
That would work for metrics (out of the box).
What about other data like alert trigger definitions?
Or group memberships?
Perhaps we look at a reaper sort of approach where we look for "dead"
resources in inventory, based on some sort of criteria, and then perform
clean-up.
> I think this is a problem to ignore. If the feed name/resource
path
> changes then it's basically new resource. I don't think
Do I understand you correctly that you say that a feed name
once set will be the same no matter where the (WF-)server
moves to? So that a resource under that feed would be the
same no matter where the feed is located.
For a WF-Server with the embedded agent, this is certainly
true.
I may may be wrong here: in OpenShift3 / Kubernetes (K8s),
K8s may kill a container at any time and start it on a different
machine. If an application consist of e.g. 3 servers, having
one killed and restarted would imply to me that all the previous
"settings" would still apply to the freshly started instance no
matter where it is then located. In this case, we should probably
record the fact of the restart, but the resource would at least
logically (from my PoV) be the same one of 3 servers of that app.
I defer to others to answer this question but if feedIds don't survive a
machine change I think we're in trouble. I rather thought a feed would
just report it's machine in some way, so that machine metrics could be
correlated to app performance.
(of course that last paragraph does not apply to explicit manual
uninventory).
I also recall from RHQ that we had a situation where a user was
deploying my-super-app-v1.war and later my-super-app-v2.war,
where both deployments are the same app and even with a different
name just two different versions of the same resource and not
different resources. Also in this case, the user wants all metrics,
trigger definitions etc. to survive the deployment of v2.
You are right about this and I hadn't forgot about it. But this feature
is a b*tch. It was really hard in RHQ and may be nigh impossible in
Hawkular unless we basically do the same thing and start stripping
versions out of resource paths. Or maybe we're already doing that, I
don't know. It depends on whether the agent is using the path as-is from
wfly, which afaik is still using the artifact name in the path.