<div dir="ltr"><div>Hello Jonas, <br></div><div>I created the proposal for the extension concerning local IP addresses in metering label rules. You can find the proposal here: <a href="https://bugs.launchpad.net/neutron/+bug/1889431">https://bugs.launchpad.net/neutron/+bug/1889431</a>. I am starting today the implementation.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 9, 2020 at 8:53 AM Rafael Weingärtner <<a href="mailto:rafaelweingartner@gmail.com">rafaelweingartner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I created a bug track for the extension of the neutron metering granularities: <a href="https://bugs.launchpad.net/neutron/+bug/1886949" target="_blank">https://bugs.launchpad.net/neutron/+bug/1886949</a></div><div>I am never sure about those "paper work", I normally propose the pull requests, and wait for the guidance of the community.</div><div><br></div><div>About the source/destination filtering, I have not published anything yet. So far, we defined/specified what we need/want from the Neutron metering sub-system. Next week I am supposed to start on this matter. Therefore, as soon as I have updates, I will create the bug report, and pull requests. You can help me now by reviewing the PR I already have open, and of course, testing/using it :)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 9, 2020 at 3:54 AM Jonas Schäfer <<a href="mailto:jonas.schaefer@cloudandheat.com" target="_blank">jonas.schaefer@cloudandheat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Rafael,<br>
<br>
On Dienstag, 7. Juli 2020 14:09:29 CEST Rafael Weingärtner wrote:<br>
> Hallo Jonas,<br>
> I have worked to address this specific use case.<br>
> <br>
> First, the part of the solution that is already implemented. If you only<br>
> need to gather metrics in a tenant fashion, you can take a look into this<br>
> PR: <a href="https://review.opendev.org/#/c/735605/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/735605/</a>. That pull request enables<br>
> operators to configure shared traffic labels, and then, these traffic<br>
> labels will be exposed/published with different granularities. The<br>
> different granularities are router, tenant, label, router-label, and<br>
> tenant-label. The complete explanation can be found in the "RST" document<br>
> that the PR also introduces, where we wrote a complete description of<br>
> neutron metering, its configs, and usage. You are welcome to review and<br>
> help us get this PR merged :)<br>
<br>
This already looks very useful to us, since it saves us from creating labels <br>
for each and every project.<br>
<br>
> So far, if all you need is to measure the whole traffic, but in different<br>
> granularities, that PR will probably be enough.<br>
<br>
Not quite; as mentioned, we’ll need to carve out specific network areas from <br>
metering, those which are in our DCs, but on the other side of the router from <br>
the customer perspective.<br>
<br>
> On the other hand,  if you<br>
> need to create more complex rules to filter by source/destination IPs, then<br>
> we need something else. Interestingly enough, we are working towards that.<br>
> We will extend neutron API, and neutron metering to allow operators to use<br>
> "remote-ip" and "source-ip" to create metering labels rules.<br>
<br>
That sounds exactly like what we’d need.<br>
<br>
> We also saw the PR that changed the behavior of the "remote-ip"  property,<br>
> and the whole confusion it caused (at least for us). However, instead of<br>
> proposing to revert it, we are working towards enabling the API to handle<br>
> "remote-ip" and "source-ip", which will cover the use case of the person<br>
> that introduced that commit, and many others such as ours and yours<br>
> (probably).<br>
<br>
Sounds good. Is there a way we can collaborate on this? Is there a launchpad <br>
bug which tracks that? (Also, is there a launchpad thing for the shared label <br>
granularity you’re doing already? I didn’t find one mentioned on the gerrit <br>
page.)<br>
<br>
kind regards,<br>
Jonas Schäfer<br>
<br>
> <br>
> On Tue, Jul 7, 2020 at 5:47 AM Jonas Schäfer <<br>
> <br>
> <a href="mailto:jonas.schaefer@cloudandheat.com" target="_blank">jonas.schaefer@cloudandheat.com</a>> wrote:<br>
> > Dear list,<br>
> > <br>
> > We are trying to implement tenant bandwidth metering at the neutron router<br>
> > level. Since some of the network spaces connected to the external<br>
> > interface of<br>
> > the neutron router are supposed to be unmetered, we need to match on the<br>
> > remote address.<br>
> > <br>
> > Conveniently, there exists a --remote-ip-prefix option on meter label<br>
> > create;<br>
> > however, since [1], its meaning was changed to the exact opposite: Instead<br>
> > of<br>
> > matching on the *remote* prefix (towards the external interface), it<br>
> > matches<br>
> > on the *local* prefix (towards the OS tenant network).<br>
> > <br>
> > In an ideal world, we would want to revert that change and instead<br>
> > introduce a<br>
> > --local-ip-prefix option which covers that use-case. I suppose this is not<br>
> > a<br>
> > thing we *should* do though, given that this change made it into a few<br>
> > releases already.<br>
> > <br>
> > Instead, we’ll have to create a new option (which whatever name) +<br>
> > associated<br>
> > database schema + iptables rule patterns to implement the feature.<br>
> > <br>
> > The questions associated with this are now:<br>
> > <br>
> > - Does this make absolutely no sense to anyone?<br>
> > - What is the process for this? I suppose since this change was made<br>
> > intentionally and passed review, our desired change needs to go through a<br>
> > feature request process (blueprints maybe?).<br>
> > <br>
> > kind regards,<br>
> > Jonas Schäfer<br>
> > <br>
> >    [1]: <a href="https://opendev.org/openstack/neutron/commit/" rel="noreferrer" target="_blank">https://opendev.org/openstack/neutron/commit/</a><br>
> > <br>
> > 92db1d4a2c49b1f675b6a9552a8cc5a417973b64<br>
> > <br>
> > <br>
> > --<br>
> > Jonas Schäfer<br>
> > DevOps Engineer<br>
> > <br>
> > Cloud&Heat Technologies GmbH<br>
> > Königsbrücker Straße 96 | 01099 Dresden<br>
> > +49 351 479 367 37<br>
> > <a href="mailto:jonas.schaefer@cloudandheat.com" target="_blank">jonas.schaefer@cloudandheat.com</a> | <a href="http://www.cloudandheat.com" rel="noreferrer" target="_blank">www.cloudandheat.com</a><br>
> > <br>
> > New Service:<br>
> > Managed Kubernetes designed for AI & ML<br>
> > <a href="https://managed-kubernetes.cloudandheat.com/" rel="noreferrer" target="_blank">https://managed-kubernetes.cloudandheat.com/</a><br>
> > <br>
> > Commercial Register: District Court Dresden<br>
> > Register Number: HRB 30549<br>
> > VAT ID No.: DE281093504<br>
> > Managing Director: Nicolas Röhrs<br>
> > Authorized signatory: Dr. Marius Feldmann<br>
> > Authorized signatory: Kristina Rübenkamp<br>
<br>
<br>
-- <br>
Jonas Schäfer<br>
DevOps Engineer<br>
<br>
Cloud&Heat Technologies GmbH<br>
Königsbrücker Straße 96 | 01099 Dresden<br>
+49 351 479 367 37<br>
<a href="mailto:jonas.schaefer@cloudandheat.com" target="_blank">jonas.schaefer@cloudandheat.com</a> | <a href="http://www.cloudandheat.com" rel="noreferrer" target="_blank">www.cloudandheat.com</a><br>
<br>
New Service:<br>
Managed Kubernetes designed for AI & ML<br>
<a href="https://managed-kubernetes.cloudandheat.com/" rel="noreferrer" target="_blank">https://managed-kubernetes.cloudandheat.com/</a><br>
<br>
Commercial Register: District Court Dresden<br>
Register Number: HRB 30549<br>
VAT ID No.: DE281093504<br>
Managing Director: Nicolas Röhrs<br>
Authorized signatory: Dr. Marius Feldmann<br>
Authorized signatory: Kristina Rübenkamp<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr">Rafael Weingärtner</div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Rafael Weingärtner</div></div>