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?**** > > ** ** >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
