Open Stack

On Tue, Aug 4, 2015 at 1:02 PM, 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.
>

​First of all maybe we should be asking this on the u/s mailing list to get
a broader view?
​


>
> 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?
>

​I think we are, they mostly fit the case but as everything in Neutron it's
unripe.
However from my experience this was the ripest option available to us..
​


>
> - - 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?
>

​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.
I'm not sure there's much value to aggregating the exceptions right off the
bat and this can be done later on.



>
> - - 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
>



-- 
Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/1205a00f/attachment.html>