Doug Hellmann wrote:
>There are a couple of other alternatives: >1. We could move notification handling into its own daemon to get it out of >the collector. This new daemon would still run on a central service, and would >need to be set up to support load balancing >just as the collector is now. The similarities are why we left the two types >of processing in the same process to begin with. >2. We could modify nova to include more details about an instance when it >publishes a notification. This is the best solution from our perspective, and >I would like to see all of the properties anyway, >but I don't know if there is a performance-related reason for leaving out some >details. This problem is either simpler than the discussion implies, or there are constraints that are not being made explicit. But to me the choice would be simple. If the data will typically be used by the receiving entity, it should be included in the notification. Asynchronously fetching the data from some form of persistent storage is making the system more complex. That complexity would only be justified if a) there was optional data that the receiver of the notification would frequently not bother to read, and the goal is to limit The bandwidth to the data that will *probably* be consumed, or b) once this data is included the total data rate becomes erratic, so limiting The notification size allows the bulk data transfer to be smoothed out without slowing down the acceptance of other notifications. In either case, building a more complex system to make delivering bulk data deferrable implies that the deferred data is large. Why not Store it in a blob (i.e. in a Swift object), rather than in a database entry?
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
