openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Wed, Jun 13, 2012 at 4:26 PM, Caitlin Bestler <
Caitlin.Bestler@xxxxxxxxxxx> 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?****
>
> ** **
>