Comment 6 for bug 1886949

Hello Slawek,
I was not able to make the meeting. Sorry, about that. My answers for the inquiries that you guys raised on the 2020-07-10 Neutron meeting are the following.

For the inquiry:
14:49:23 <slaweq> looking at the proposed change of the message format I'm not sure if we need another config knob for that
14:49:51 <slaweq> we could maybe simply add some new fields to the existing message so it would be backward compatible always
14:49:54 <slaweq> wdyt?

I created the configuration to make it backward compatible. I was not sure by whom and how the current implementation is being used. Therefore, I created a parameter to enable/disable the implementation. It seemed more natural, and we can deprecate the “legacy mode” with time, and just use the new format proposed.

14:50:53 <mlavalle> would the receiving end be confused by the "new fields"?

Yes, it would (in my opinion). It is not just about new fields; it is about separating the different aggregation methods into different metering messages. We need that to be able to process them properly in Ceilometer.

14:51:55 <njohnston> Does this granularity imply an increase in the number of emssages sent to the notification queue?

Yes, it does. With the new format, instead of one message per label per report time frame, we would have in the worst case (1 message per label + 1 message per router + 1 message per tenant + 1 message per label-tenant + 1 message per label-router) per report time frame. However, one must bear in mind that these report time frames are configurable. Therefore, one can set it to 30-60min. The guys using this right now are using 10min for the report time frame in a reasonably sized environment without any problems.

14:52:38 <njohnston> If message volume will increase that is something that an operator might want to be able to turn off, if their RabbitMQ is stressed.

That is another reason why I created the parameter. In the worst case, the operator could just use the legacy mode. However, there is always the possibility of using larger report intervals and/or larger data-gathering intervals. All of these configurations are described in detail in the documentation I wrote for the Neutron metering implementation.

I guess those were all of the questions I found in the meeting. If you guys have any other questions, suggestions, or comments concerning this implementation, please do not hesitate to ping me.

And, by the way, I am working on another extension for the Neutron-metering system to allow remote and source IP filtering withint label rules. I just mention that to show you guys that there are indeed people using it (the metering agent) and working to make it better.