Open Stack

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.

-Bob

On 8/4/15 2:26 PM, Abhishek Raut wrote:
> 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] https://review.openstack.org/#/c/202061/
>
> ‹Abhishek Raut
>
> On 8/4/15, 3:02 AM, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:
>
>> -----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:
>>
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
>> /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
> >from the extension, assuming that ml2 will propagate it to the user in
>> some form.
>>
>> But it does not work. This is because _call_on_ext_drivers swallows
>> exceptions:
>>
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
>> /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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/fb1f4151/attachment.html>