yahoo-eng-team team mailing list archive

[LIU Yulong <yulong@xxxxxxxxxxxxx>]

Public bug reported:

For now, L3 IPs are all have bandwidth QoS functionality. Floating IPs and gateway IPs have the same TC rules. And for one specific IP, it can not be set in two hosts for current neutron architecture. That is saying, where the IP is working, we can get the TC statistic data for it. Yes, the TC filter rules have that data for us:
https://review.openstack.org/#/c/453458/10/neutron/agent/linux/l3_tc_lib.py@143

Command line example:
# ip netns exec snat-867e1473-4495-4513-8759-dee4cb1b9cef tc -s -d -p filter show dev qg-91293cf7-64
filter parent 1: protocol ip pref 1 u32 
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid :1 not_in_hw  (rule hit 180 success 180)
  match IP src 172.16.100.10/32 (success 180 ) 
 police 0x2 rate 1024Kbit burst 128Kb mtu 64Kb action drop overhead 0b linklayer ethernet 
	ref 1 bind 1 installed 86737 sec used 439 sec

 Sent 17640 bytes 180 pkts (dropped 0, overlimits 0)

So, we can use this data to enable the L3 IPs metering directly by l3
agent itself. Because we have that TC filters for all the statistic data
we need. neutron metering agent seems now not so much widely used, and
it is a little heavy for cloud users.

About how to deal with the data:
1. retrieve the data from the TC rules periodically
2. store the data to local store file
3. report the data to ceilometer/metering service via RPC notification or UDP
4. some other service like zabbix read the local store data

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1817881

Title:
   [RFE] L3 IPs monitor/metering via current QoS functionality (tc
  filters)

Status in neutron:
  New

Bug description:
  For now, L3 IPs are all have bandwidth QoS functionality. Floating IPs and gateway IPs have the same TC rules. And for one specific IP, it can not be set in two hosts for current neutron architecture. That is saying, where the IP is working, we can get the TC statistic data for it. Yes, the TC filter rules have that data for us:
  https://review.openstack.org/#/c/453458/10/neutron/agent/linux/l3_tc_lib.py@143

  Command line example:
  # ip netns exec snat-867e1473-4495-4513-8759-dee4cb1b9cef tc -s -d -p filter show dev qg-91293cf7-64
  filter parent 1: protocol ip pref 1 u32 
  filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 
  filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid :1 not_in_hw  (rule hit 180 success 180)
    match IP src 172.16.100.10/32 (success 180 ) 
   police 0x2 rate 1024Kbit burst 128Kb mtu 64Kb action drop overhead 0b linklayer ethernet 
  	ref 1 bind 1 installed 86737 sec used 439 sec

   Sent 17640 bytes 180 pkts (dropped 0, overlimits 0)

  So, we can use this data to enable the L3 IPs metering directly by l3
  agent itself. Because we have that TC filters for all the statistic
  data we need. neutron metering agent seems now not so much widely
  used, and it is a little heavy for cloud users.

  About how to deal with the data:
  1. retrieve the data from the TC rules periodically
  2. store the data to local store file
  3. report the data to ceilometer/metering service via RPC notification or UDP
  4. some other service like zabbix read the local store data

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1817881/+subscriptions