Open Stack

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200707/49b848ee/attachment.html>