Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2015 08:41 PM, Robert Kukura wrote: 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. I am not sure they should be returned as-is, since those exceptions may map to InternalError in the server unless inherited properly. Anyway, I think the patch in question reached some level of maturity that would need attention from ml2 and api people: https://review.openstack.org/#/c/202061 Bob and others, please take a look. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVxETvAAoJEC5aWaUY1u57OPIH/iKYuuLjWUyiq8l1BGQjx26+ sgsiWsYqjQxbKvU/LDmPK6bAcv2ElsMSWhWzBFGFe/XVFxNp8GmLCRrWN3XhW2lD PVrApIwGsf0jMMiqRCuBGBIV4RxCqVUKYF8yETRphsDuaK8iYMwwsQl3feITddTf byTMQS78GeFZGhyX2CVUge5oiVdLuCit22F8QdyndntttfYciOb7jKhhTGZuanhv Xf1dkGGx+D6vuj90F0Ng9EuESDbFBgmEMkcMAWUGsgI+vjLwWHZD+D788gWjGsFp QHiAxDVmJ94WNxBouoAOgpWVv+OwQ0Lmd+9LXHwFd/1cBbY9oPai8CgftQUV47o= =htRR -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
[openstack-dev] [neutron][qos][ml2] extensions swallow exceptions
-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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions
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
Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions
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 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. 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions
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 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. 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
