Don't we have something on the server side now to tell the agent: "hey i'm busy, come back to me later, but in the meantime spool your data" Would it be possible to tweak this so the server could be put in this state, but still be able to communicate with an a agent sufficiently to tell it to deploy a bundle?
We're going to have to think how we're going to deal with upgrades too right, e.g. upgrade from RHQ5 to 6, moves from cassandra 1.2 to 1.3.
That's a potentially related issue?
----- Original Message -----I have started thinking about how we will deploy our new metrics back_______________________________________________
end. So far I have been operating under the assumption that we will
deploy Cassandra nodes with our provisioning system. The problem of
bootstrapping ourselves in this fashion is that it introduces
circular dependencies. Deploying a Cassandra node requires a running
agent. A running agent implies MeasurementManager is initialized and
is collecting metrics. The agent needs a back end to store metric
data.
One possibility is to not fully initialize MeasurementManager until
we have Cassandra up and running. This would require either the
server to send notification to all agents so the each
MeasurementManager instance can start up and start collecting
metrics. Or the agent/MeasurementManager could poll the server to
see when it can start collecting metrics. Neither of these is
particularly appealing to me.
Anyone have thoughts on an alternative bootstrapping approach?
- John
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel