[Hawkular-dev] Remove / rename servers from / in inventory

[Jay Shaughnessy]

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.