Hallo Jonas, I have worked to address this specific use case. First, the part of the solution that is already implemented. If you only need to gather metrics in a tenant fashion, you can take a look into this PR: https://review.opendev.org/#/c/735605/. That pull request enables operators to configure shared traffic labels, and then, these traffic labels will be exposed/published with different granularities. The different granularities are router, tenant, label, router-label, and tenant-label. The complete explanation can be found in the "RST" document that the PR also introduces, where we wrote a complete description of neutron metering, its configs, and usage. You are welcome to review and help us get this PR merged :) So far, if all you need is to measure the whole traffic, but in different granularities, that PR will probably be enough. On the other hand, if you need to create more complex rules to filter by source/destination IPs, then we need something else. Interestingly enough, we are working towards that. We will extend neutron API, and neutron metering to allow operators to use "remote-ip" and "source-ip" to create metering labels rules. We also saw the PR that changed the behavior of the "remote-ip" property, and the whole confusion it caused (at least for us). However, instead of proposing to revert it, we are working towards enabling the API to handle "remote-ip" and "source-ip", which will cover the use case of the person that introduced that commit, and many others such as ours and yours (probably). On Tue, Jul 7, 2020 at 5:47 AM Jonas Schäfer < jonas.schaefer@cloudandheat.com> wrote:
Dear list,
We are trying to implement tenant bandwidth metering at the neutron router level. Since some of the network spaces connected to the external interface of the neutron router are supposed to be unmetered, we need to match on the remote address.
Conveniently, there exists a --remote-ip-prefix option on meter label create; however, since [1], its meaning was changed to the exact opposite: Instead of matching on the *remote* prefix (towards the external interface), it matches on the *local* prefix (towards the OS tenant network).
In an ideal world, we would want to revert that change and instead introduce a --local-ip-prefix option which covers that use-case. I suppose this is not a thing we *should* do though, given that this change made it into a few releases already.
Instead, we’ll have to create a new option (which whatever name) + associated database schema + iptables rule patterns to implement the feature.
The questions associated with this are now:
- Does this make absolutely no sense to anyone? - What is the process for this? I suppose since this change was made intentionally and passed review, our desired change needs to go through a feature request process (blueprints maybe?).
kind regards, Jonas Schäfer
[1]: https://opendev.org/openstack/neutron/commit/ 92db1d4a2c49b1f675b6a9552a8cc5a417973b64
-- Jonas Schäfer DevOps Engineer
Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 37 jonas.schaefer@cloudandheat.com | www.cloudandheat.com
New Service: Managed Kubernetes designed for AI & ML https://managed-kubernetes.cloudandheat.com/
Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann Authorized signatory: Kristina Rübenkamp
-- Rafael Weingärtner