Don't know why subject wasn't set automatically.. On Tue, Aug 4, 2015 at 3:30 PM, Mike Kolesnik <mkole...@redhat.com> wrote:
> > > 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 >> <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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Regards, > Mike > -- 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