OpenStack - User contributions [en]

Trove/guest agent communication

2013-09-30T18:22:19Z

Edward Konetzko: /* Phase ???? */

== Guest agent communication ==
[[File:TroveGACurrent.png|framed|center]]
There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# Multiple security implications with current design

=== Phase 1 ===
==== Remove guest agent from writing heartbeats directly to infra database ====

[[File:TroveGAPhase1.png|framed|center]]

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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===
[[File:TroveGAPhase2.png|framed|center]]
1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

=== Phase 3 ===
[[File:TroveGAPhase3.png|framed|center]]

1. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Phase 4 ===

[[File:TroveGAPhase4.png|framed|center]]

Move all agent communication to work though the trove-conductor

=== Phase 5 ===

Get community to agree on defined message protocol in json for talking to guest agent.

1. First step of protocol outlined in Phase 1 with heartbeat message.
2. Document the rest of the protocol for discussion.

File:TroveGAPhase4.png

2013-09-30T18:19:45Z

Edward Konetzko:

Trove/guest agent communication

2013-09-30T18:13:31Z

Edward Konetzko:

== Guest agent communication ==
[[File:TroveGACurrent.png|framed|center]]
There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# Multiple security implications with current design

=== Phase 1 ===
==== Remove guest agent from writing heartbeats directly to infra database ====

[[File:TroveGAPhase1.png|framed|center]]

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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===
[[File:TroveGAPhase2.png|framed|center]]
1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

=== Phase 3 ===
[[File:TroveGAPhase3.png|framed|center]]

1. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Phase ???? ===

Move all agent communication to work though the trove-conductor using defined application protocol in json.

Trove/guest agent communication

2013-09-30T18:11:14Z

Edward Konetzko: /* Phase 3 */

== Guest agent communication ==
[[File:TroveGACurrent.png|framed|center]]
There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# Multiple security implications with current design

=== Phase 1 ===
==== Remove guest agent from writing heartbeats directly to infra database ====

[[File:TroveGAPhase1.png|framed|center]]

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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===
[[File:TroveGAPhase2.png|framed|center]]
1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

=== Phase 3 ===
[[File:TroveGAPhase3.png|framed|center]]

1. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

File:TroveGAPhase3.png

2013-09-30T18:10:44Z

Edward Konetzko:

File:TroveGAPhase2.png

2013-09-30T18:03:07Z

Edward Konetzko: Edward Konetzko uploaded a new version of "File:TroveGAPhase2.png"

Phase 2 GA communication method

Trove/guest agent communication

2013-09-30T17:44:36Z

Edward Konetzko: /* Phase 2 */

== Guest agent communication ==
[[File:TroveGACurrent.png|framed|center]]
There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# Multiple security implications with current design

=== Phase 1 ===
==== Remove guest agent from writing heartbeats directly to infra database ====

[[File:TroveGAPhase1.png|framed|center]]

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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===
[[File:TroveGAPhase2.png|framed|center]]
1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

=== Phase 3 ===

1. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

File:TroveGAPhase2.png

2013-09-30T17:43:33Z

Edward Konetzko: Phase 2 GA communication method

Phase 2 GA communication method

File:TroveGAPhase1.png

2013-09-30T17:39:13Z

Edward Konetzko: Edward Konetzko uploaded a new version of "File:TroveGAPhase1.png"

Phase one of guest agent communication changes.

File:TroveGAPhase1.png

2013-09-30T17:37:54Z

Edward Konetzko: Edward Konetzko uploaded a new version of "File:TroveGAPhase1.png"

Phase one of guest agent communication changes.

Trove/guest agent communication

2013-09-30T17:36:25Z

Edward Konetzko:

== Guest agent communication ==
[[File:TroveGACurrent.png|framed|center]]
There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# Multiple security implications with current design

=== Phase 1 ===
==== Remove guest agent from writing heartbeats directly to infra database ====

[[File:TroveGAPhase1.png|framed|center]]

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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

File:TroveGAPhase1.png

2013-09-30T17:34:51Z

Edward Konetzko: Phase one of guest agent communication changes.

Phase one of guest agent communication changes.

Trove/guest agent communication

2013-09-30T16:40:23Z

Edward Konetzko: /* Guest agent communication */

== Guest agent communication ==
[[File:TroveGACurrent.png|framed|center]]
There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

File:TroveGACurrent.png

2013-09-30T16:38:32Z

Edward Konetzko: Current Guest Agent communication method.

Current Guest Agent communication method.

File:Current.png

2013-09-30T16:36:07Z

Edward Konetzko: Edward Konetzko uploaded a new version of "File:Current.png"

Heat - Current Autoscaling architecture.

File:Current.png

2013-09-30T16:34:42Z

Edward Konetzko: Edward Konetzko uploaded a new version of "File:Current.png"

Heat - Current Autoscaling architecture.

Trove/guest agent communication

2013-09-19T21:09:34Z

Edward Konetzko: /* Heartbeat message definition */

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "uuid of instance",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-09-19T21:08:53Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instance_id": "",
"heartbeat": {
"service_status": "running",
"service_type": "mysql"
}
}
=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-27T18:03:48Z

Edward Konetzko: /* Future direction */

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instanceID": "UUID OF THE INSTANCE"
"heartbeat": [
{ "agentstatus":"online" , "mysqlstatus":"running" }
]
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-27T18:03:15Z

Edward Konetzko: /* Phase 2 */

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instanceID": "UUID OF THE INSTANCE"
"heartbeat": [
{ "agentstatus":"online" , "mysqlstatus":"running" }
]
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. This would also allow us to store information that the api currently asks the guest-agent for such as volume space used. The real goal of having a flexible heartbeat message would be to create a data store that could be used for internal reporting purposes.

=== Future direction ===

Ideas to finish writing about
# Write heartbeats to a different data store, api's servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heartbeat. Ideas tossed around were MySQL version and/or guest agent version but the possibilities would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory data store, response was if it doesnt show up it must not be on-line.

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-19T18:46:25Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instanceID": "UUID OF THE INSTANCE"
"heartbeat": [
{ "agentstatus":"online" , "mysqlstatus":"running" }
]
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database but using RPC calls between the two managers.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. For example one could extend the heartbeat to include the version of mysql packages and/or guest-agent version to create an in memory reporting data store. Some of these extended attributes could be returned back to the customers but the real benefit would be to give operations insight into the customers instances without having to query the instances.

=== Future direction ===

Ideas to finish writing about
# Write heartbeats to a different data store, api's servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heartbeat. Ideas tossed around were MySQL version and/or guest agent version but the possibilities would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory data store, response was if it doesnt show up it must not be on-line.

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-19T18:43:01Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instanceID": "UUID OF THE INSTANCE"
"heartbeat": [
{ "agentstatus":"online" , "mysqlstatus":"running" }
]
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database.

2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

The logic behind providing a way to map array attributes in the heartbeat message is so that this could be extended as each deployment sees fit. For example one could extend the heartbeat to include the version of mysql packages and/or guest-agent version to create an in memory reporting data store. Some of these extended attributes could be returned back to the customers but the real benefit would be to give operations insight into the customers instances without having to query the instances.

=== Future direction ===

Ideas to finish writing about
# Write heartbeats to a different data store, api's servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heartbeat. Ideas tossed around were MySQL version and/or guest agent version but the possibilities would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory data store, response was if it doesnt show up it must not be on-line.

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-19T18:31:59Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

{
"instanceID": "UUID OF THE INSTANCE"
"heartbeat": [
{ "agentstatus":"online" , "mysqlstatus":"running" }
]
}

=== Phase 2 ===

1. Change Trove to contact trove-conductor for heartbeat status on the instance and no longer check the database.
2. Abstract out the status data store in a way that attributes in heartbeat message can be mapped to fields in the data store.

=== Future direction ===

Ideas to finish writing about
# Write heartbeats to a different data store, api's servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heartbeat. Ideas tossed around were MySQL version and/or guest agent version but the possibilities would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory data store, response was if it doesnt show up it must not be on-line.

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-19T18:27:57Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

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

=== Phase 2 ===

Change Trove to contact trove-conductor for status on the instance and no longer check the database.

=== Future direction ===

Ideas to finish writing about
# Write heartbeats to a different data store, api's servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heartbeat. Ideas tossed around were MySQL version and/or guest agent version but the possibilities would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory data store, response was if it doesnt show up it must not be on-line.

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-15T19:30:26Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

Regardless of transport used the heartbeat message should always be in json. Attribute "heartbeat" should be an array that way it is extensible in the future.

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

=== Future direction ===

Ideas to finish writing about
# Write heartbeats to a different data store, api's servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heartbeat. Ideas tossed around were MySQL version and/or guest agent version but the possibilities would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory data store, response was if it doesnt show up it must not be on-line.

# Move all agent communication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-15T19:24:58Z

Edward Konetzko:

== Guest agent communication ==

There are the following issues with the guest agents communication method.
# Heartbeats are directly written to the infrastructure database
# Multiple heartbeats 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 infrastructure and right now only rabbitmq.
# 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 task manager 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 data store 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

One heartbeat should be sent every 60 seconds. There is a possibility of the guest-agent being able to send an ad-hoc heartbeat if it were to detect a status change in any of the components it reporting on. For example it could send a heartbeat saying mysql is active every 60 seconds but the guest agent could check MySQL locally every 10. With this option if there was a state change in MySQL e.g. it crashed 20 seconds into the next heartbeat the status could be updated in an ad-hoc update immediately. This should cut down on heartbeat chatter while still being flexible enough to reflect status changes immediately.

==== Heartbeat message definition ====

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 ===

Ideas to finish wrting about
# Write heartbeats to a different datastore, apis servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heatbeat. Ideas tossed around were mysql version and/or guest agent version but the possiblitys would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory datastore, response was if it doesnt show up it must not be online.

# Move all agent commuication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/maintenance-windows-and-version-updates

2013-08-08T19:32:17Z

Edward Konetzko: Edward Konetzko moved page Reddwarf-maintenance-windows-and-version-updates to Trove/maintenance-windows-and-version-updates: Project renamed, better location

== Maintenance Windows==

=== Create Database Instance ===

POST /instances Creates a new database instance.

'''New Attributes''' 
maintenanceWindow, optional 
format: YYYY-MM-DDThh:mmZ/YYYY-MM-DDThh:mmZ 

'''Response Codes:''' same as current call 
'''Error Codes:''' same as current call 
'''Description:''' 
'''Request Body:''' 

{
"instance": {
"databases": [
{
"character_set": "utf8",
"collate": "utf8_general_ci",
"name": "sampledb"
},
{
"name": "nextround"
}
],
"flavorRef": "https://service/v1.0/1234/flavors/1",
"name": "my_db_inst",
"volume": {
"size": 2
}
"typeRef": "https://service/v1.0/1234/type/1",
"maintenanceWindow":"2012-03-28T21:30Z/2012-03-28T22:00Z"
}
}

== Modify Database Instance ==

PUT /instances/{instanceId}

New Attributes
maintenanceWindow, optional
format: YYYY-MM-DDThh:mmZ/YYYY-MM-DDThh:mmZ
default: will need defaults set if there is no window specified

'''Response Codes:''' same as current call 
'''Error Codes:''' same as current call 
'''Description:''' 
'''Request Body:''' 

{
"instance": {
"maintenanceWindow":"2012-03-28T21:30Z/2012-03-28T22:00Z"
}
}

=== List Database Instance Status and Details (Existing Call) ===

GET /instances/{instanceId} Lists status and details for a specified database instance.

'''Response Codes:''' same as original cal 
'''Error Codes:''' same as original call 
'''Description:''' 
'''Request Body:''' This operation does not require a request body. 
'''Response:''' 

{
"instance": {
"created": "2012-03-28T21:31:02Z",
"flavor": {
"id": "1",
"links": [
...
]
},
"hostname": "hostname",
"id": "2450c73f-7805-4afe-a42c-4094ab42666b",
"links": [
...
],
"name": "my_db_inst",
"status": "ACTIVE",
"updated": "2012-03-28T21:34:25Z",
"volume": {
"size": 2,
"used": 0.124542236328125
}
"maintenanceWindow":"2012-03-28T21:30Z/2012-03-28T22:00Z"
}
}

== MySQL Updates ==

As a Reddwarf User, I need to the ability to manage MySQL version updates, so that I can minize unimplanned downtime and plan accordingly for my production application environments.

=== Update Instance ===

POST/instances/{instanceId}/action Update the instance to the latest database version.

'''Response Codes:''' same as original call 
'''Error Codes:''' Call should validate if updates are needed and return an error/message if updates are not needed 
'''Request Body:''' 

{
"update": {}
}

Reddwarf-maintenance-windows-and-version-updates

2013-08-08T19:32:17Z

Edward Konetzko: Edward Konetzko moved page Reddwarf-maintenance-windows-and-version-updates to Trove/maintenance-windows-and-version-updates: Project renamed, better location

#REDIRECT [[Trove/maintenance-windows-and-version-updates]]

Trove/guest agent communication

2013-08-08T19:00:48Z

Edward Konetzko:

== 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 and right now only rabbitmq.
# 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

==== Heartbeat message definition ====

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 ===

Ideas to finish wrting about
# Write heartbeats to a different datastore, apis servers would need updates to talk to trove-conductor for status information.
# Allow for expanded information to be passed back in the heatbeat. Ideas tossed around were mysql version and/or guest agent version but the possiblitys would be endless. With this it was thought that we could possible create an in memory reporting database to gather information on instance w/o having to query all instances. The idea of keeping it in memory is because non of the information is stored for historical value and if it was all lost it would be populated in one heartbeat cycle. There was a question brought up on what happens when an instance shows up as no in the in memory datastore, response was if it doesnt show up it must not be online.

# Move all agent commuication to work though the trove-conductor
# ????
# Profit

Yea need to finish up this section :D

Trove/guest agent communication

2013-08-08T18:50:34Z

Edward Konetzko:

Trove/guest agent communication

2013-08-08T18:49:35Z

Edward Konetzko:

Trove/guest agent communication

2013-08-08T17:41:05Z

Edward Konetzko:

Trove/guest agent communication

2013-08-08T17:05:26Z

Edward Konetzko: 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..."