On Fri, Jun 15, 2012 at 10:34 AM, Doug Hellmann <doug.hellm...@dreamhost.com > wrote:
> > > On Wed, Jun 13, 2012 at 4:26 PM, Caitlin Bestler < > caitlin.best...@nexenta.com> wrote: > >> 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, >> > > I was concerned about both, but I am convinced that the right solution is > to include all of the details about the instance in the notification data > generated by nova. I am going to work on that patch. > > >> 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? >> > The changes to nova to add the extra data to outgoing notifications is ready for review at https://review.openstack.org/#/c/8659/
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
