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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
