Open Stack

Don't know why subject wasn't set automatically..

On Tue, Aug 4, 2015 at 3:30 PM, Mike Kolesnik <mkolesni at redhat.com> wrote:

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

Don't mind this, I must be drunk..​


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



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