Trove/guest agent communication

Guest agent communication

There are the following issues with the guest agents communication method.

1. Heatbeats are directly written to the infrastructure database
2. 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.
3. Uses the same transport as the rest of the infrstrucuture and right now only rabbitmq.
4. Multiple security implications with current design

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. It was expressed in the meeting that it would be nice to store to datastore besides the infra database, while those ideas were accepted it was noted as out of scope for first pass.

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 heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extenedable in the future.

   {
       "heartbeat": [
           { "agentstatus":"online" , "mysqlstatus":"running" }
       ]
   }

Future direction

1. Move all agent commuication to work though the trove-conductor
2.  ????
3. Profit

Yea need to finish up this section :D