On Tue, Aug 4, 2015 at 1:02 PM, Ihar Hrachyshka <ihrac...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Mike
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
