<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<meta charset="utf-8">
The process_[create|update]_<resource>() extension driver
methods are intended to validate user input. Exceptions raised by
these need to be returned to users so they know what they did wrong.
These exceptions should not be logged as anything higher than info
level, since user errors generally are not of concern to admins.
Also, given that these methods are called within the create or
update transaction, raising an exception will cause the entire
transaction to be rolled back. Once an exceptions occurs in an
extension driver, there is no point in continuing to call the other
extension drivers since only one exception will be returned to the
user at a time.<br>
<br>
-Bob<br>
<br>
<div class="moz-cite-prefix">On 8/4/15 2:26 PM, Abhishek Raut wrote:<br>
</div>
<blockquote cite="mid:D1E65096.17E2%25rauta@vmware.com" type="cite">
<pre wrap="">There is this review[1] trying to solve exactly what you¹re asking for.
I think it makes sense for the exceptions to be propagated all the way
back to the user instead of swallowing them and then roll back the
transaction. Does it even make sense to continue after a failure?
[1] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/202061/">https://review.openstack.org/#/c/202061/</a>
‹Abhishek Raut
On 8/4/15, 3:02 AM, "Ihar Hrachyshka" <a class="moz-txt-link-rfc2396E" href="mailto:ihrachys@redhat.com"><ihrachys@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
in feature/qos, we use ml2 extension drivers to handle additional
qos_policy_id field that can be provided thru API:
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2</a>
/extensions/qos.py?h=feature/qos
What we do in qos extension is we create a database 'binding' object
between the updated port and the QoS policy that corresponds to
qos_policy_id. So we access the database. It means there may be some
complications there, f.e. the policy object is not available for the
tenant, or just does not exist. In that case, we raise an exception
</pre>
</blockquote>
<pre wrap="">>from the extension, assuming that ml2 will propagate it to the user in
</pre>
<blockquote type="cite">
<pre wrap="">some form.
But it does not work. This is because _call_on_ext_drivers swallows
exceptions:
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2</a>
/managers.py#n766
It makes me ask some questions:
- - first, do we use extensions as was expected? Can we extend
extensions to cover our use case?
- - second, what would be the right way to go assuming we want to
support the case? Should we just reraise? Or maybe postpone till all
extension drivers are called, and then propagate an exception top into
the stack? (Probably some extension manager specific exception?) Or
maybe we want extensions to claim whether they may raise, and handle
them accordingly?
- - alternatively, if we abuse the API and should stop doing it, which
other options do we have to achieve similar behaviour without relying
on ml2 extensions AND without polluting ml2 driver with qos specific cod
e?
Thanks for your answers,
Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz
tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw
BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF
kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq
HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV
psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=
=Fo++
-----END PGP SIGNATURE-----
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>