openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Fri, Jun 15, 2012 at 10:34 AM, Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx
> wrote:

>
>
> 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?
>>
>
The changes to nova to add the extra data to outgoing notifications is
ready for review at https://review.openstack.org/#/c/8659/