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

Hi, Is there any reason the agent can't use container as identification? HOSTNAME="hawkular-cassandra-1-6o1y8" I guess that's exported to all Openshift containers at least (I don't have Kubernetes instance to check). Unfortunately the image id was not there, but that hostname includes the container-name + generated id. If you deploy additional instances, you get a new id, redeploy - new id. - Micke ----- Original Message ----- From: "John Mazzitelli" <mazz(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Thursday, July 28, 2016 6:58:30 PM Subject: Re: [Hawkular-dev] Identification of WildFly in container in a Kube/Openshift env chicken and the egg - agent needs to know its feed ID before it can even put anything into inventory. But the fact an agent can change its feed ID via inventory REST call is interesting. However, that might not fly because its more than Inventory we are worried about. The agent stores things in Hawkular *Metrics* that refer to the (now old) feed ID (like metric IDs and metric tag names and values). I don't like this talk of changing feed IDs at runtime. This goes against everything we talked about and designed when we started. Feeds identify an agent - and a feed ID should never change (at least, that's what we said up until now, and everything is implemented in the agent with that assumption in mind). Allowing an agent to change its feed ID during its lifetime is going to cause problems - probably even problems we haven't thought of yet. IMO, feed IDs need to be locked. An agent, once it determines its feed ID and registers it, should never change that feed ID. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev