<div dir="ltr"><div class="gmail_default" style="font-size:small">Don't know why subject wasn't set automatically..<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 3:30 PM, Mike Kolesnik <span dir="ltr"><<a href="mailto:mkolesni@redhat.com" target="_blank">mkolesni@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 1:02 PM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hi all,<br>
<br>
in feature/qos, we use ml2 extension drivers to handle additional<br>
qos_policy_id field that can be provided thru API:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/extensions/qos.py?h=feature/qos" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2<br>
/extensions/qos.py?h=feature/qos</a><br>
<br>
What we do in qos extension is we create a database 'binding' object<br>
between the updated port and the QoS policy that corresponds to<br>
qos_policy_id. So we access the database. It means there may be some<br>
complications there, f.e. the policy object is not available for the<br>
tenant, or just does not exist. In that case, we raise an exception<br>
from the extension, assuming that ml2 will propagate it to the user in<br>
some form.<br></blockquote><div><br><div style="font-size:small;display:inline">First of all maybe we should be asking this on the u/s mailing list to get a broader view?<br></div></div></div></div></div></blockquote><div><div class="gmail_default" style="font-size:small;display:inline"><br>Don't mind this, I must be drunk..</div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-size:small;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But it does not work. This is because _call_on_ext_drivers swallows<br>
exceptions:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/managers.py#n766" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2<br>
/managers.py#n766</a><br>
<br>
It makes me ask some questions:<br>
<br>
- - first, do we use extensions as was expected? Can we extend<br>
extensions to cover our use case?<br></blockquote><div><br><div style="font-size:small;display:inline">I think we are, they mostly fit the case but as everything in Neutron it's unripe.<br></div><div style="font-size:small;display:inline">However from my experience this was the ripest option available to us..<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- - second, what would be the right way to go assuming we want to<br>
support the case? Should we just reraise? Or maybe postpone till all<br>
extension drivers are called, and then propagate an exception top into<br>
the stack? (Probably some extension manager specific exception?) Or<br>
maybe we want extensions to claim whether they may raise, and handle<br>
them accordingly?<br></blockquote><div><br><div style="font-size:small">I was thinking in order not to alter existing extension behaviours that we can define in the ML2 extension driver scope a special exception type (sort of exception container), and if an exception of this type is raised then we should re-raise it.<br></div><div style="font-size:small">I'm not sure there's much value to aggregating the exceptions right off the bat and this can be done later on.<br><br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- - alternatively, if we abuse the API and should stop doing it, which<br>
other options do we have to achieve similar behaviour without relying<br>
on ml2 extensions AND without polluting ml2 driver with qos specific cod<br>
e?<br>
<br>
Thanks for your answers,<br>
Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz<br>
tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw<br>
BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF<br>
kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq<br>
HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV<br>
psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=<br>
=Fo++<br>
-----END PGP SIGNATURE-----<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr"><div style="font-size:large"><font size="2">Regards,</font><br></div>Mike</div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div style="font-size:large"><font size="2">Regards,</font><br></div>Mike</div></div>
</div></div>