Re: [openstack-dev] [neutron] extension implemented by multiple plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/19/2015 10:54 AM, Bence Romsics wrote: Hi, I'm not sure I need it. :-) My first idea was, that if two plugins implement an extension together (neither the new first class resource, nor the new port attributes is a usable feature in themselves in my case), then it would be nice to express this. However thinking a bit more, I believe the only practical difference between your solution in the qos patches and my first idea is that we could catch some bad neutron configurations (ie. loading only one of the two plugins). Which is probably really rare, so it does not seem to justify the extra complexity. So I will just go with your stuff. Thanks. Well, if we can move into dreams area, we may think of a way to express such inter-dependency, f.e. by introducing hidden sub-extensions; and meta-extensions that are satisfied only if all sub-extension pieces are present. But we like simple solutions, so we just hacked around the limitation. Our fault. :) Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV1FfcAAoJEC5aWaUY1u57QrAH/A7qwU0EI9GE7yLI3pKckxnQ 7WJrjeLkewJkAH4LgPPkrD37ENgvKihF7MeEONzLaGll3OPp0xqTMGelLf+xPQ83 Cp2FNvG32kBi9EI/ge/VNxKBqpP+b6GcVP+UiH87dL4o35GHdbdC8uopKXjjDEKL uP2yVvJNz2IsojPUgbNw7GlWsP43EL93Piig6T7aRpApafSair3unc0/FbiYZlD/ WGepc+vwni+NC+Hk8PAb2jKCWA7xNvmZzpFKrTvY7Z75t0AK39a6SdCPbUvjwU/9 XL+gcPOggLq9LElZjdnyEW+EmVO0euAbl3YYLbyPdJWxM4d3sk+KGQCBhfwgsOs= =B0T+ -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] extension implemented by multiple plugins
Hi, I'm not sure I need it. :-) My first idea was, that if two plugins implement an extension together (neither the new first class resource, nor the new port attributes is a usable feature in themselves in my case), then it would be nice to express this. However thinking a bit more, I believe the only practical difference between your solution in the qos patches and my first idea is that we could catch some bad neutron configurations (ie. loading only one of the two plugins). Which is probably really rare, so it does not seem to justify the extra complexity. So I will just go with your stuff. Thanks. Cheers, Bence On Tue, Aug 18, 2015 at 4:02 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/18/2015 03:11 PM, Bence Romsics wrote: Hi Ihar, Thank you. Just rebased my patch and following the example of the qos feature now I can start neutron-server with both the service plugin and the ml2 extension driver loaded. However I have noticed that I can no longer mark the extension driver as implementing the extension alias (the 'extension_alias' property seems to be better not used, or I still have the same error). Is that intentional? I think the assumption is that only one plugin is capable of implementing an extension. We only allowed to implement no extensions at all. If you think we should allow multiple plugins to claim support for the same extension, then it's an additional use case on top of what we needed in qos. Why do you need it? BTW feature/qos was merged in master yesterday, so it's now available for all patches. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV0zrZAAoJEC5aWaUY1u57DIAIAJG+U3sVI/ejvEmETEtbINH+ mm8IFhpwoSzMNcRKfrlobgmu4R/+saGfQsUaQHjh4ko7PVq2eDH9sMPlHjVZXUGi x5Rt7gKuFCXsPLyXybjAaaWQjI/hO65/V7D1xwQceRl9FL6kSjgxoasu5ufGUR4j ZMmp0f9nN8v7VVHynhLq0FEYMqMs0fylO2hnyJKyJUk26Xd1GZqv/58jAl6RaB3Z LzE6Qd6yO0R4ekEhL4DhBbf3+J59ljDhgCbCvScKiL83IZb0FT4vcYMvuHIKezHt c23ImDJjz9ZCCld0ah39/jEcqOWj8IM41L/1Qjwdk/Fn/s1CUtFY1vJ28z8IOgg= =rMZ7 -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] extension implemented by multiple plugins
Hi Ihar, Thank you. Just rebased my patch and following the example of the qos feature now I can start neutron-server with both the service plugin and the ml2 extension driver loaded. However I have noticed that I can no longer mark the extension driver as implementing the extension alias (the 'extension_alias' property seems to be better not used, or I still have the same error). Is that intentional? Cheers, Bence On Mon, Aug 17, 2015 at 4:46 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/17/2015 04:35 PM, Bence Romsics wrote: Hi All, How do I implement one extension by two plugins? If I extend the API by: * a first class resource, and * attributes to an already existing resource (the port resource in my case). These two parts don't make sense without each other, so I'd like to keep this as one extension, not two. That's exactly what we needed in feature/qos: we have new QoS policy and rules objects, and we extend networks and ports with qos_policy_id. Then naturally I'd like to implement: * the first class resource as a service plugin, and * the new port attributes as an ml2 extension driver. And straightforwardly I put the same extension alias into both the service plugin and the ml2 extension driver. Then I get this error: File /opt/stack/neutron/neutron/manager.py, line 199, in _load_service_plugins ValueError: Multiple plugins for service TRUNK_PORT were configured Indeed it does not currently allow it. But in feature/qos, we solved it as in line 760: https://review.openstack.org/#/c/203105/6/neutron/plugins/ml2/managers.p y And the feature/qos branch is scheduled to merge back into master in next days: https://review.openstack.org/212170 So you can base your work on top of the merge patch and claim problem solved. :) Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV0fO1AAoJEC5aWaUY1u57SgEIAJYy3UAjqT4NXF8CdNfy3jcv 5dw4fqktjlj0yaiOOGM+J98vi3wVTnz+qQsk+jkS5M/0hySYQyo0M8JPF38PlRIW Jw5vjZJZjdOivn3y/fccGq7ph3T0KTYPvCyc2nThVxGxaFB/mb4TLuZlGzXh2vYt PsIjW15V56zIhHK2oS9t32DAfd64fvz86BfpNwuizKLAqyqnO84fWysxuK8P5rnC 2S67YmP3DeC0IhVbDLNs1Gzpk4mMpQpbRIHiZR2gIVFswy4EKuwoDjDY0AgVb0zw 6+BovJNdm1BWiNbQgNnn6K2LC53Nsc95WQzLeticzvLGGyG7cz4pMyraIDoBfqg= =OKeU -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] extension implemented by multiple plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/18/2015 03:11 PM, Bence Romsics wrote: Hi Ihar, Thank you. Just rebased my patch and following the example of the qos feature now I can start neutron-server with both the service plugin and the ml2 extension driver loaded. However I have noticed that I can no longer mark the extension driver as implementing the extension alias (the 'extension_alias' property seems to be better not used, or I still have the same error). Is that intentional? I think the assumption is that only one plugin is capable of implementing an extension. We only allowed to implement no extensions at all. If you think we should allow multiple plugins to claim support for the same extension, then it's an additional use case on top of what we needed in qos. Why do you need it? BTW feature/qos was merged in master yesterday, so it's now available for all patches. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV0zrZAAoJEC5aWaUY1u57DIAIAJG+U3sVI/ejvEmETEtbINH+ mm8IFhpwoSzMNcRKfrlobgmu4R/+saGfQsUaQHjh4ko7PVq2eDH9sMPlHjVZXUGi x5Rt7gKuFCXsPLyXybjAaaWQjI/hO65/V7D1xwQceRl9FL6kSjgxoasu5ufGUR4j ZMmp0f9nN8v7VVHynhLq0FEYMqMs0fylO2hnyJKyJUk26Xd1GZqv/58jAl6RaB3Z LzE6Qd6yO0R4ekEhL4DhBbf3+J59ljDhgCbCvScKiL83IZb0FT4vcYMvuHIKezHt c23ImDJjz9ZCCld0ah39/jEcqOWj8IM41L/1Qjwdk/Fn/s1CUtFY1vJ28z8IOgg= =rMZ7 -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] extension implemented by multiple plugins
Hi All, How do I implement one extension by two plugins? If I extend the API by: * a first class resource, and * attributes to an already existing resource (the port resource in my case). These two parts don't make sense without each other, so I'd like to keep this as one extension, not two. Then naturally I'd like to implement: * the first class resource as a service plugin, and * the new port attributes as an ml2 extension driver. And straightforwardly I put the same extension alias into both the service plugin and the ml2 extension driver. Then I get this error: File /opt/stack/neutron/neutron/manager.py, line 199, in _load_service_plugins ValueError: Multiple plugins for service TRUNK_PORT were configured IMHO prohibiting two plugins of the same type was good logic when we had service plugins only, but now that we have ml2 extension drivers too it seems to be buggy logic. What do you think? Shall we change this logic? Maybe keep track of two sets of plugins, one for service plugins and one for ml2 extension drivers? Or do you know some other way? For further details it seems to me the following files and methods are implementing the current logic: neutron/plugins/ml2/plugin.py: Ml2Plugin.supported_extension_aliases() neutron/plugins/ml2/managers.py: ExtensionManager.extension_aliases() neutron/manager.py: NeutronManager._load_service_plugins() NeutronManager._load_services_from_core_plugin() Thanks in advance, Bence __ 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] extension implemented by multiple plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/17/2015 04:35 PM, Bence Romsics wrote: Hi All, How do I implement one extension by two plugins? If I extend the API by: * a first class resource, and * attributes to an already existing resource (the port resource in my case). These two parts don't make sense without each other, so I'd like to keep this as one extension, not two. That's exactly what we needed in feature/qos: we have new QoS policy and rules objects, and we extend networks and ports with qos_policy_id. Then naturally I'd like to implement: * the first class resource as a service plugin, and * the new port attributes as an ml2 extension driver. And straightforwardly I put the same extension alias into both the service plugin and the ml2 extension driver. Then I get this error: File /opt/stack/neutron/neutron/manager.py, line 199, in _load_service_plugins ValueError: Multiple plugins for service TRUNK_PORT were configured Indeed it does not currently allow it. But in feature/qos, we solved it as in line 760: https://review.openstack.org/#/c/203105/6/neutron/plugins/ml2/managers.p y And the feature/qos branch is scheduled to merge back into master in next days: https://review.openstack.org/212170 So you can base your work on top of the merge patch and claim problem solved. :) Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV0fO1AAoJEC5aWaUY1u57SgEIAJYy3UAjqT4NXF8CdNfy3jcv 5dw4fqktjlj0yaiOOGM+J98vi3wVTnz+qQsk+jkS5M/0hySYQyo0M8JPF38PlRIW Jw5vjZJZjdOivn3y/fccGq7ph3T0KTYPvCyc2nThVxGxaFB/mb4TLuZlGzXh2vYt PsIjW15V56zIhHK2oS9t32DAfd64fvz86BfpNwuizKLAqyqnO84fWysxuK8P5rnC 2S67YmP3DeC0IhVbDLNs1Gzpk4mMpQpbRIHiZR2gIVFswy4EKuwoDjDY0AgVb0zw 6+BovJNdm1BWiNbQgNnn6K2LC53Nsc95WQzLeticzvLGGyG7cz4pMyraIDoBfqg= =OKeU -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
