Difference between revisions of "Trove/guest agent communication"
(Created page with "== Guest agent communication == There are the following issues with the guest agents communication method. # Heatbeats are directly written to the infrastructure database # M...") |
|||
| Line 4: | Line 4: | ||
# Heatbeats are directly written to the infrastructure database | # Heatbeats are directly written to the infrastructure database | ||
# Mutiple heatbeats used when one will do. There is no need to send a heartbeat saying the agent is up and one for the database state. We know the agent is up if it is reporting the database status. | # Mutiple heatbeats used when one will do. There is no need to send a heartbeat saying the agent is up and one for the database state. We know the agent is up if it is reporting the database status. | ||
| − | # Uses the same transport as | + | # Uses the same transport as the rest of the infrstrucuture |
| Line 10: | Line 10: | ||
==== Remove guest agent from writing heartbeats directly to infra database ==== | ==== Remove guest agent from writing heartbeats directly to infra database ==== | ||
| − | Remove heartbeats being written to the database directly via guest agent. | + | Remove heartbeats being written to the database directly via guest agent. This would solve a huge security issue along with cutting down on connection load to the infra db. |
Kenneth Wilke proposed this blueprint https://blueprints.launchpad.net/trove/+spec/taskmanager-statusupdate | Kenneth Wilke proposed this blueprint https://blueprints.launchpad.net/trove/+spec/taskmanager-statusupdate | ||
It was decided in the weekly meeting to not extend taskmanager to handle this but write another manager called trove-conductor that would handle heartbeat updates to the infra database. | It was decided in the weekly meeting to not extend taskmanager to handle this but write another manager called trove-conductor that would handle heartbeat updates to the infra database. | ||
| + | http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-07-20.00.html | ||
| + | |||
| + | http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-07-20.00.log.html | ||
| + | |||
| + | Regardless of transport used the message should always be in json | ||
| + | |||
| + | { | ||
| + | "heartbeat": [ | ||
| + | { "agentstatus":"online" , "mysqlstatus":"running" } | ||
| + | ] | ||
| + | } | ||
Revision as of 17:41, 8 August 2013
Guest agent communication
There are the following issues with the guest agents communication method.
- Heatbeats are directly written to the infrastructure database
- Mutiple heatbeats used when one will do. There is no need to send a heartbeat saying the agent is up and one for the database state. We know the agent is up if it is reporting the database status.
- Uses the same transport as the rest of the infrstrucuture
Phase 1
Remove guest agent from writing heartbeats directly to infra database
Remove heartbeats being written to the database directly via guest agent. This would solve a huge security issue along with cutting down on connection load to the infra db.
Kenneth Wilke proposed this blueprint https://blueprints.launchpad.net/trove/+spec/taskmanager-statusupdate
It was decided in the weekly meeting to not extend taskmanager to handle this but write another manager called trove-conductor that would handle heartbeat updates to the infra database. http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-07-20.00.html
http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-07-20.00.log.html
Regardless of transport used the message should always be in json
{
"heartbeat": [
{ "agentstatus":"online" , "mysqlstatus":"running" }
]
}
