Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
On 12/17/2015 04:45 PM, Ihar Hrachyshka wrote: Rossella Sblendidowrote: Hi Ihar, wow, good job!! Sorry for the very slow reply. I really like your proposal...some comments inline. On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote: Hi, Small update on the RFE. It was approved for Mitaka, assuming we come up with proper details upfront thru neutron-specs process. In the meantime, we have found more use cases for flow management among features in development: QoS DSCP, also the new OF based firewall driver. Both authors for those new features independently realized that agent does not currently play nice with flows set by external code due to its graceful restart behaviour when rules with unknown cookies are cleaned up. [The agent uses a random session uuid() to mark rules that belong to its current run.] Before I proceed, full disclosure: I know almost nothing about OpenFlow capabilities, so some pieces below may make no sense. I tried to come up with high level model first and then try to map it to available OF features. Please don’t hesitate to comment, I like to learn new stuff! ;) I am not an expert either so I encourage people to chime in here. I am thinking lately on the use cases we collected so far. One common need for all features that were seen to be interested in proper integration with Open vSwitch agent is to be able to manage feature specific flows on br-int and br-tun. There are other things that projects may need, like patch ports, though I am still struggling with the question of whether it may be postponed or avoided for phase 1. There are several specific operation 'kinds' that we should cover for the RFE: - managing flows that modify frames in-place; - managing flows that redirect frames. There are some things that should be considered to make features cooperate with the agent and other extensions: - feature flows should have proper priorities based on their ‘kind’ (f.e. in-place modification probably go before redirections); - feature flows should survive flow reset that may be triggered by the agent; - feature flows should survive flow reset without data plane disruption (=they should support graceful restart: https://review.openstack.org/#/c/182920). With that in mind, I see the following high level design for the flow tables: - table 0 serves as a dispatcher for specific features; - each feature gets one or more tables, one per flow ‘kind’ needed; - for each feature table, a new flow entry is added to table 0 that would redirect to feature specific table; the rule will be triggered only if OF metadata is not updated inside the feature table (see the next bullet); the rule will have priority that is defined for the ‘kind’ of the operation that is implemented by the table it redirects to; - each feature table will have default actions that will 1) mark OF metadata for the frame as processed by the feature; 2) redirect back to table 0; - all feature specific flow rules (except dispatcher rules) belong to feature tables; Now, the workflow for extensions that are interested in setting flows would be: - on initialize() call, extension defines feature tables it will need; Do you mean this in a dynamic way or every extension will have tables assigned, basically hard-coded? I prefer the second way so we have more controls of the tables that are currently used. Do you suggest creating several tables even if an extension is not interested in all of them? As for the table name, I guess we may build it as agent_cookie + extension name so that it’s clear which tables were bootstrapped in current session, and which can be cleaned up after we clear flows from previous sessions. I like this. it passes the name of the feature table and the ‘kind’ of the actions it will execute; with that, the following is initialized by the agent: 1) It would be nice to pass also a filter to match some packets. We probably don't want to send all the packet to the feature table, the extension can define that. It probably stands for some optimization, though I am not sure how serious. If we go this route, we also need to short-circuit metadata marking on filter unmatched, or do we expect other extensions to influence filter matching? I am not sure how it would look like. Do we allow random matching filters, or enforce some base types and leave more detailed filters to extension tables? Let's leave it for later then. You are right, that's probably an early optimization table 0 dispatcher entry to redirect frames into feature table; the entry has the priority according to the ‘kind’ of the table; 2) the I think we need to define the priority better. According to what you wrote we assign priority based on "in-place modification probably go before redirections" not sure if it's enough. What happens if we have two features that both requires in place-modifications? How do we prioritize them? Are we going to allow 2 extension at the same time? Let me think
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
On 12/17/2015 05:07 PM, Ihar Hrachyshka wrote: We may probably think of passing agent uuid into extensions to allow it to be used as a cookie for their flows, and make sure extensions are triggered before we reset obsolete flows in the agent. It may work. I would only want to see it as a temporary solution. One thing that I would like to tackle with the proposal is keeping our main flow tables clean from extension specific flows, if anything, for easier debugging. I agree with you here. Let's pass the uuid as a temporary solution. This will buy us some time to iterate on the extensions flow tables proposal and get it working. In the meanwhile the subprojects that install flows won't be blocked. cheers, Rossella __ 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] How could an L2 agent extension access agent methods ?
Rossella Sblendidowrote: Hi Ihar, wow, good job!! Sorry for the very slow reply. I really like your proposal...some comments inline. On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote: Hi, Small update on the RFE. It was approved for Mitaka, assuming we come up with proper details upfront thru neutron-specs process. In the meantime, we have found more use cases for flow management among features in development: QoS DSCP, also the new OF based firewall driver. Both authors for those new features independently realized that agent does not currently play nice with flows set by external code due to its graceful restart behaviour when rules with unknown cookies are cleaned up. [The agent uses a random session uuid() to mark rules that belong to its current run.] Before I proceed, full disclosure: I know almost nothing about OpenFlow capabilities, so some pieces below may make no sense. I tried to come up with high level model first and then try to map it to available OF features. Please don’t hesitate to comment, I like to learn new stuff! ;) I am not an expert either so I encourage people to chime in here. I am thinking lately on the use cases we collected so far. One common need for all features that were seen to be interested in proper integration with Open vSwitch agent is to be able to manage feature specific flows on br-int and br-tun. There are other things that projects may need, like patch ports, though I am still struggling with the question of whether it may be postponed or avoided for phase 1. There are several specific operation 'kinds' that we should cover for the RFE: - managing flows that modify frames in-place; - managing flows that redirect frames. There are some things that should be considered to make features cooperate with the agent and other extensions: - feature flows should have proper priorities based on their ‘kind’ (f.e. in-place modification probably go before redirections); - feature flows should survive flow reset that may be triggered by the agent; - feature flows should survive flow reset without data plane disruption (=they should support graceful restart: https://review.openstack.org/#/c/182920). With that in mind, I see the following high level design for the flow tables: - table 0 serves as a dispatcher for specific features; - each feature gets one or more tables, one per flow ‘kind’ needed; - for each feature table, a new flow entry is added to table 0 that would redirect to feature specific table; the rule will be triggered only if OF metadata is not updated inside the feature table (see the next bullet); the rule will have priority that is defined for the ‘kind’ of the operation that is implemented by the table it redirects to; - each feature table will have default actions that will 1) mark OF metadata for the frame as processed by the feature; 2) redirect back to table 0; - all feature specific flow rules (except dispatcher rules) belong to feature tables; Now, the workflow for extensions that are interested in setting flows would be: - on initialize() call, extension defines feature tables it will need; Do you mean this in a dynamic way or every extension will have tables assigned, basically hard-coded? I prefer the second way so we have more controls of the tables that are currently used. Do you suggest creating several tables even if an extension is not interested in all of them? As for the table name, I guess we may build it as agent_cookie + extension name so that it’s clear which tables were bootstrapped in current session, and which can be cleaned up after we clear flows from previous sessions. it passes the name of the feature table and the ‘kind’ of the actions it will execute; with that, the following is initialized by the agent: 1) It would be nice to pass also a filter to match some packets. We probably don't want to send all the packet to the feature table, the extension can define that. It probably stands for some optimization, though I am not sure how serious. If we go this route, we also need to short-circuit metadata marking on filter unmatched, or do we expect other extensions to influence filter matching? I am not sure how it would look like. Do we allow random matching filters, or enforce some base types and leave more detailed filters to extension tables? table 0 dispatcher entry to redirect frames into feature table; the entry has the priority according to the ‘kind’ of the table; 2) the I think we need to define the priority better. According to what you wrote we assign priority based on "in-place modification probably go before redirections" not sure if it's enough. What happens if we have two features that both requires in place-modifications? How do we prioritize them? Are we going to allow 2 extension at the same time? Let me think more about this...It would be nice to have some real world example… I assumed that multiple extensions don’t mess
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Hi Ihar, wow, good job!! Sorry for the very slow reply. I really like your proposal...some comments inline. On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote: Hi, Small update on the RFE. It was approved for Mitaka, assuming we come up with proper details upfront thru neutron-specs process. In the meantime, we have found more use cases for flow management among features in development: QoS DSCP, also the new OF based firewall driver. Both authors for those new features independently realized that agent does not currently play nice with flows set by external code due to its graceful restart behaviour when rules with unknown cookies are cleaned up. [The agent uses a random session uuid() to mark rules that belong to its current run.] Before I proceed, full disclosure: I know almost nothing about OpenFlow capabilities, so some pieces below may make no sense. I tried to come up with high level model first and then try to map it to available OF features. Please don’t hesitate to comment, I like to learn new stuff! ;) I am not an expert either so I encourage people to chime in here. I am thinking lately on the use cases we collected so far. One common need for all features that were seen to be interested in proper integration with Open vSwitch agent is to be able to manage feature specific flows on br-int and br-tun. There are other things that projects may need, like patch ports, though I am still struggling with the question of whether it may be postponed or avoided for phase 1. There are several specific operation 'kinds' that we should cover for the RFE: - managing flows that modify frames in-place; - managing flows that redirect frames. There are some things that should be considered to make features cooperate with the agent and other extensions: - feature flows should have proper priorities based on their ‘kind’ (f.e. in-place modification probably go before redirections); - feature flows should survive flow reset that may be triggered by the agent; - feature flows should survive flow reset without data plane disruption (=they should support graceful restart: https://review.openstack.org/#/c/182920). With that in mind, I see the following high level design for the flow tables: - table 0 serves as a dispatcher for specific features; - each feature gets one or more tables, one per flow ‘kind’ needed; - for each feature table, a new flow entry is added to table 0 that would redirect to feature specific table; the rule will be triggered only if OF metadata is not updated inside the feature table (see the next bullet); the rule will have priority that is defined for the ‘kind’ of the operation that is implemented by the table it redirects to; - each feature table will have default actions that will 1) mark OF metadata for the frame as processed by the feature; 2) redirect back to table 0; - all feature specific flow rules (except dispatcher rules) belong to feature tables; Now, the workflow for extensions that are interested in setting flows would be: - on initialize() call, extension defines feature tables it will need; Do you mean this in a dynamic way or every extension will have tables assigned, basically hard-coded? I prefer the second way so we have more controls of the tables that are currently used. it passes the name of the feature table and the ‘kind’ of the actions it will execute; with that, the following is initialized by the agent: 1) It would be nice to pass also a filter to match some packets. We probably don't want to send all the packet to the feature table, the extension can define that. table 0 dispatcher entry to redirect frames into feature table; the entry has the priority according to the ‘kind’ of the table; 2) the I think we need to define the priority better. According to what you wrote we assign priority based on "in-place modification probably go before redirections" not sure if it's enough. What happens if we have two features that both requires in place-modifications? How do we prioritize them? Are we going to allow 2 extension at the same time? Let me think more about this...It would be nice to have some real world example... actual feature table with two default rules (update metadata and push back to table 0); - whenever extension needs to add a new flow rule, it passes the following into the agent: 1) table name; 2) flow specific parameters (actions, priority, ...) Since the agent will manage setting flows for extensions, it will be able to use the active agent cookie for all feature flows; next time the agent is restarted, it should be able to respin extension flows with no data plane disruption. [Note: we should make sure that on agent restart, we call to extensions *before* we clean up stale flow rules.] I like this :) That design will hopefully allow us to abstract interaction with flows from extensions into management code inside the agent. It should guarantee extensions cooperate properly assuming they properly define their
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
hi, On Fri, Dec 4, 2015 at 12:46 AM, Ihar Hrachyshkawrote: > Hi, > > Small update on the RFE. It was approved for Mitaka, assuming we come up > with proper details upfront thru neutron-specs process. > > In the meantime, we have found more use cases for flow management among > features in development: QoS DSCP, also the new OF based firewall driver. > Both authors for those new features independently realized that agent does > not currently play nice with flows set by external code due to its graceful > restart behaviour when rules with unknown cookies are cleaned up. [The agent > uses a random session uuid() to mark rules that belong to its current run.] > > Before I proceed, full disclosure: I know almost nothing about OpenFlow > capabilities, so some pieces below may make no sense. I tried to come up > with high level model first and then try to map it to available OF features. > Please don’t hesitate to comment, I like to learn new stuff! ;) > > I am thinking lately on the use cases we collected so far. One common need > for all features that were seen to be interested in proper integration with > Open vSwitch agent is to be able to manage feature specific flows on br-int > and br-tun. There are other things that projects may need, like patch ports, > though I am still struggling with the question of whether it may be > postponed or avoided for phase 1. i suspect port management is mandatory for many of usecases. > > There are several specific operation 'kinds' that we should cover for the > RFE: > - managing flows that modify frames in-place; > - managing flows that redirect frames. > > There are some things that should be considered to make features cooperate > with the agent and other extensions: > - feature flows should have proper priorities based on their ‘kind’ (f.e. > in-place modification probably go before redirections); > - feature flows should survive flow reset that may be triggered by the > agent; > - feature flows should survive flow reset without data plane disruption > (=they should support graceful restart: > https://review.openstack.org/#/c/182920). > > With that in mind, I see the following high level design for the flow > tables: > > - table 0 serves as a dispatcher for specific features; > - each feature gets one or more tables, one per flow ‘kind’ needed; > - for each feature table, a new flow entry is added to table 0 that would > redirect to feature specific table; the rule will be triggered only if OF > metadata is not updated inside the feature table (see the next bullet); the > rule will have priority that is defined for the ‘kind’ of the operation that > is implemented by the table it redirects to; > - each feature table will have default actions that will 1) mark OF > metadata for the frame as processed by the feature; 2) redirect back to > table 0; > - all feature specific flow rules (except dispatcher rules) belong to > feature tables; > > Now, the workflow for extensions that are interested in setting flows would > be: > - on initialize() call, extension defines feature tables it will need; it > passes the name of the feature table and the ‘kind’ of the actions it will > execute; with that, the following is initialized by the agent: 1) table 0 > dispatcher entry to redirect frames into feature table; the entry has the > priority according to the ‘kind’ of the table; 2) the actual feature table > with two default rules (update metadata and push back to table 0); > - whenever extension needs to add a new flow rule, it passes the following > into the agent: 1) table name; 2) flow specific parameters (actions, > priority, ...) "actions" here means openflow actions? passing openflow actions as parameters is not simple as it might sound because they are complex objects. esp. when we have two backends. (ovs-ofctl and native of_interface) > > Since the agent will manage setting flows for extensions, it will be able to > use the active agent cookie for all feature flows; next time the agent is > restarted, it should be able to respin extension flows with no data plane > disruption. [Note: we should make sure that on agent restart, we call to > extensions *before* we clean up stale flow rules.] > > That design will hopefully allow us to abstract interaction with flows from > extensions into management code inside the agent. It should guarantee > extensions cooperate properly assuming they properly define their priorities > thru ‘kinds’ of tables they have. > > It is also assumed that existing flow based features integrated into the > agent (dvr? anti-spoofing?) will eventually move to the new flow table > management model. > > I understand that the model does not reflect how do feature processing for > existing OF based features in the agent. It may require some smart > workarounds to allow non-disruptive migration to new flow table setup. > > It would be great to see the design bashed hard before I start to put it > into spec format. Especially if
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Hi, Small update on the RFE. It was approved for Mitaka, assuming we come up with proper details upfront thru neutron-specs process. In the meantime, we have found more use cases for flow management among features in development: QoS DSCP, also the new OF based firewall driver. Both authors for those new features independently realized that agent does not currently play nice with flows set by external code due to its graceful restart behaviour when rules with unknown cookies are cleaned up. [The agent uses a random session uuid() to mark rules that belong to its current run.] Before I proceed, full disclosure: I know almost nothing about OpenFlow capabilities, so some pieces below may make no sense. I tried to come up with high level model first and then try to map it to available OF features. Please don’t hesitate to comment, I like to learn new stuff! ;) I am thinking lately on the use cases we collected so far. One common need for all features that were seen to be interested in proper integration with Open vSwitch agent is to be able to manage feature specific flows on br-int and br-tun. There are other things that projects may need, like patch ports, though I am still struggling with the question of whether it may be postponed or avoided for phase 1. There are several specific operation 'kinds' that we should cover for the RFE: - managing flows that modify frames in-place; - managing flows that redirect frames. There are some things that should be considered to make features cooperate with the agent and other extensions: - feature flows should have proper priorities based on their ‘kind’ (f.e. in-place modification probably go before redirections); - feature flows should survive flow reset that may be triggered by the agent; - feature flows should survive flow reset without data plane disruption (=they should support graceful restart: https://review.openstack.org/#/c/182920). With that in mind, I see the following high level design for the flow tables: - table 0 serves as a dispatcher for specific features; - each feature gets one or more tables, one per flow ‘kind’ needed; - for each feature table, a new flow entry is added to table 0 that would redirect to feature specific table; the rule will be triggered only if OF metadata is not updated inside the feature table (see the next bullet); the rule will have priority that is defined for the ‘kind’ of the operation that is implemented by the table it redirects to; - each feature table will have default actions that will 1) mark OF metadata for the frame as processed by the feature; 2) redirect back to table 0; - all feature specific flow rules (except dispatcher rules) belong to feature tables; Now, the workflow for extensions that are interested in setting flows would be: - on initialize() call, extension defines feature tables it will need; it passes the name of the feature table and the ‘kind’ of the actions it will execute; with that, the following is initialized by the agent: 1) table 0 dispatcher entry to redirect frames into feature table; the entry has the priority according to the ‘kind’ of the table; 2) the actual feature table with two default rules (update metadata and push back to table 0); - whenever extension needs to add a new flow rule, it passes the following into the agent: 1) table name; 2) flow specific parameters (actions, priority, ...) Since the agent will manage setting flows for extensions, it will be able to use the active agent cookie for all feature flows; next time the agent is restarted, it should be able to respin extension flows with no data plane disruption. [Note: we should make sure that on agent restart, we call to extensions *before* we clean up stale flow rules.] That design will hopefully allow us to abstract interaction with flows from extensions into management code inside the agent. It should guarantee extensions cooperate properly assuming they properly define their priorities thru ‘kinds’ of tables they have. It is also assumed that existing flow based features integrated into the agent (dvr? anti-spoofing?) will eventually move to the new flow table management model. I understand that the model does not reflect how do feature processing for existing OF based features in the agent. It may require some smart workarounds to allow non-disruptive migration to new flow table setup. It would be great to see the design bashed hard before I start to put it into spec format. Especially if it’s not sane. :) Ihar Mathieu Rohonwrote: Thanks ihar! On Thu, Nov 19, 2015 at 2:32 PM, Ihar Hrachyshka wrote: UPD: now that we have some understanding what’s needed from l2 agent extension mechanism to cater for interested subprojects (and now that we see that probably the agent in focus right now is OVS only), we may move to RFE step. I reported
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Thanks ihar! On Thu, Nov 19, 2015 at 2:32 PM, Ihar Hrachyshkawrote: > UPD: now that we have some understanding what’s needed from l2 agent > extension mechanism to cater for interested subprojects (and now that we > see that probably the agent in focus right now is OVS only), we may move to > RFE step. I reported the following RFE for the feature: > > https://bugs.launchpad.net/neutron/+bug/1517903 > > It may require BP if drivers team will request one. > > Cheers, > > Ihar > > Ihar Hrachyshka wrote: > > Reviving the thread. >> >> On the design summit session dedicated to agent and plugin extensions [1] >> the following was stated for l2 agent extensions (I appreciate if someone >> checks me on the following though): >> >> - current l2 agent extensions mechanism lacks insight into agent details >> like bridges or vlan maps; >> >> - in some cases, we don’t care about extension portability across >> multiple agents, so it’s not of concern if some of them use implementation >> details like bridges to set specific flows, or to wire up some additional >> ports to them; >> >> - that said, we still don’t want extensions to have unlimited access to >> agent details; the rationale for hard constraints on what is seen inside >> extensions is that we cannot support backwards compatibility for *all* >> possible internal attributes of an agent; instead, we should explicitly >> define where we can make an effort to provide stable API into agent >> details, and what’s, on contrary, beyond real life use cases and hence can >> be left to be broken/refactored as neutron developers see fit; this API can >> be agent specific though; >> >> - agent details that are to be passed into extensions should be driven by >> actual use cases. There were several subprojects mentioned in the session >> that are assumed to lack enough access to agent attributes to do their job >> without patching core ovs agent files. Those are: BGP-VPN, SFC, (anything >> else?) Those subprojects that are interested in extending l2 agent >> extension framework are expected to come up with a list of things missing >> in current implementation, so that neutron developers can agree on proper >> abstractions to provide missing details to extensions. For that goal, I set >> up a new etherpad to collect feedback from subprojects [2]. >> >> Once we collect use cases there and agree on agent API for extensions >> (even if per agent type), we will implement it and define as stable API, >> then pass objects that implement the API into extensions thru extension >> manager. If extensions support multiple agent types, they can still >> distinguish between which API to use based on agent type string passed into >> extension manager. >> >> I really hope we start to collect use cases early so that we have time to >> polish agent API and make it part of l2 extensions earlier in Mitaka cycle. >> >> [1]: https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility >> [2]: https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion >> >> Ihar >> >> Ihar Hrachyshka wrote: >> >> On 30 Sep 2015, at 12:53, Miguel Angel Ajo wrote: Ihar Hrachyshka wrote: > On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: >> >> Hi Ihar, >> >> Ihar Hrachyshka : >> >>> Miguel Angel Ajo : > Do you have a rough idea of what operations you may need to do? > Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) >>> Sounds very tightly coupled to OVS agent. >>> Please bear in mind, the extension interface will be available from > different agent types > (OVS, SR-IOV, [eventually LB]), so this interface you're talking > about could also serve as > a translation driver for the agents (where the translation is > possible), I totally understand > that most extensions are specific agent bound, and we must be able > to identify > the agent we're serving back exactly. > Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. >>> Indeed it does. Maybe you can try to define the needed pieces in >>> high level actions, not internal objects you need to access to. Like ‘- >>> connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. >>> >> I've been thinking about this, but would tend to reach the conclusion >> that the things we need to interact with are pretty hard to abstract out >> into something that would be
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
UPD: now that we have some understanding what’s needed from l2 agent extension mechanism to cater for interested subprojects (and now that we see that probably the agent in focus right now is OVS only), we may move to RFE step. I reported the following RFE for the feature: https://bugs.launchpad.net/neutron/+bug/1517903 It may require BP if drivers team will request one. Cheers, Ihar Ihar Hrachyshkawrote: Reviving the thread. On the design summit session dedicated to agent and plugin extensions [1] the following was stated for l2 agent extensions (I appreciate if someone checks me on the following though): - current l2 agent extensions mechanism lacks insight into agent details like bridges or vlan maps; - in some cases, we don’t care about extension portability across multiple agents, so it’s not of concern if some of them use implementation details like bridges to set specific flows, or to wire up some additional ports to them; - that said, we still don’t want extensions to have unlimited access to agent details; the rationale for hard constraints on what is seen inside extensions is that we cannot support backwards compatibility for *all* possible internal attributes of an agent; instead, we should explicitly define where we can make an effort to provide stable API into agent details, and what’s, on contrary, beyond real life use cases and hence can be left to be broken/refactored as neutron developers see fit; this API can be agent specific though; - agent details that are to be passed into extensions should be driven by actual use cases. There were several subprojects mentioned in the session that are assumed to lack enough access to agent attributes to do their job without patching core ovs agent files. Those are: BGP-VPN, SFC, (anything else?) Those subprojects that are interested in extending l2 agent extension framework are expected to come up with a list of things missing in current implementation, so that neutron developers can agree on proper abstractions to provide missing details to extensions. For that goal, I set up a new etherpad to collect feedback from subprojects [2]. Once we collect use cases there and agree on agent API for extensions (even if per agent type), we will implement it and define as stable API, then pass objects that implement the API into extensions thru extension manager. If extensions support multiple agent types, they can still distinguish between which API to use based on agent type string passed into extension manager. I really hope we start to collect use cases early so that we have time to polish agent API and make it part of l2 extensions earlier in Mitaka cycle. [1]: https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility [2]: https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion Ihar Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:53, Miguel Angel Ajo wrote: Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) Sounds very tightly coupled to OVS agent. Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. I've been thinking about this, but would tend to reach the conclusion that the things we need to interact with are pretty hard to abstract out into something that would be generic across different agents. Everything we need to do in our case relates to how the agents use bridges and represent networks internally: linuxbridge has one bridge per Network, while OVS has a limited number of bridges playing different roles for all networks with internal segmentation. To look at the two things you mention: - "connect endpoint X to Y" : what we need to do is redirect the traffic destinated to the gateway of a Neutron network, to the thing that will do the MPLS forwarding for the right BGP
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Hi Ihar, Ihar Hrachyshka : Reviving the thread. [...] (I appreciate if someone checks me on the following though): This is an excellent recap. I set up a new etherpad to collect feedback from subprojects [2]. I've filled in details for networking-bgpvpn. Please tell me if you need more information. Once we collect use cases there and agree on agent API for extensions (even if per agent type), we will implement it and define as stable API, then pass objects that implement the API into extensions thru extension manager. If extensions support multiple agent types, they can still distinguish between which API to use based on agent type string passed into extension manager. I really hope we start to collect use cases early so that we have time to polish agent API and make it part of l2 extensions earlier in Mitaka cycle. We'll be happy to validate the applicability of this approach as soon as something is ready. Thanks for taking up this work! -Thomas Ihar Hrachyshkawrote: On 30 Sep 2015, at 12:53, Miguel Angel Ajo wrote: Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) Sounds very tightly coupled to OVS agent. Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. I've been thinking about this, but would tend to reach the conclusion that the things we need to interact with are pretty hard to abstract out into something that would be generic across different agents. Everything we need to do in our case relates to how the agents use bridges and represent networks internally: linuxbridge has one bridge per Network, while OVS has a limited number of bridges playing different roles for all networks with internal segmentation. To look at the two things you mention: - "connect endpoint X to Y" : what we need to do is redirect the traffic destinated to the gateway of a Neutron network, to the thing that will do the MPLS forwarding for the right BGP VPN context (called VRF), in our case br-mpls (that could be done with an OVS table too) ; that action might be abstracted out to hide the details specific to OVS, but I'm not sure on how to name the destination in a way that would be agnostic to these details, and this is not really relevant to do until we have a relevant context in which the linuxbridge would pass packets to something doing MPLS forwarding (OVS is currently the only option we support for MPLS forwarding, and it does not really make sense to mix linuxbridge for Neutron L2/L3 and OVS for MPLS) - "determine segmentation id for a network": this is something really OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and does not rely on internal segmentation Completely abstracting out packet forwarding pipelines in OVS and linuxbridge agents would possibly allow defining an interface that agent extension could use without to know about anything specific to OVS or the linuxbridge, but I believe this is a very significant taks to tackle. If you look for a clean way to integrate with reference agents, then it’s something that we should try to achieve. I agree it’s not an easy thing. Just an idea: can we have a resource for traffic forwarding, similar to security groups? I know folks are not ok with extending security groups API due to compatibility reasons, so maybe fwaas is the place to experiment with it. Hopefully it will be acceptable to create an interface, even it exposes a set of methods specific to the linuxbridge agent and a set of methods specific to the OVS agent. That would mean that the agent extension that can work in both contexts (not our case yet) would check the agent type before using the first set or the second set. The assumption of the whole idea of l2 agent extensions is that they are agent agnostic. In case of QoS, we implemented a common QoS extension that
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Reviving the thread. On the design summit session dedicated to agent and plugin extensions [1] the following was stated for l2 agent extensions (I appreciate if someone checks me on the following though): - current l2 agent extensions mechanism lacks insight into agent details like bridges or vlan maps; - in some cases, we don’t care about extension portability across multiple agents, so it’s not of concern if some of them use implementation details like bridges to set specific flows, or to wire up some additional ports to them; - that said, we still don’t want extensions to have unlimited access to agent details; the rationale for hard constraints on what is seen inside extensions is that we cannot support backwards compatibility for *all* possible internal attributes of an agent; instead, we should explicitly define where we can make an effort to provide stable API into agent details, and what’s, on contrary, beyond real life use cases and hence can be left to be broken/refactored as neutron developers see fit; this API can be agent specific though; - agent details that are to be passed into extensions should be driven by actual use cases. There were several subprojects mentioned in the session that are assumed to lack enough access to agent attributes to do their job without patching core ovs agent files. Those are: BGP-VPN, SFC, (anything else?) Those subprojects that are interested in extending l2 agent extension framework are expected to come up with a list of things missing in current implementation, so that neutron developers can agree on proper abstractions to provide missing details to extensions. For that goal, I set up a new etherpad to collect feedback from subprojects [2]. Once we collect use cases there and agree on agent API for extensions (even if per agent type), we will implement it and define as stable API, then pass objects that implement the API into extensions thru extension manager. If extensions support multiple agent types, they can still distinguish between which API to use based on agent type string passed into extension manager. I really hope we start to collect use cases early so that we have time to polish agent API and make it part of l2 extensions earlier in Mitaka cycle. [1]: https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility [2]: https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion Ihar Ihar Hrachyshkawrote: On 30 Sep 2015, at 12:53, Miguel Angel Ajo wrote: Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) Sounds very tightly coupled to OVS agent. Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. I've been thinking about this, but would tend to reach the conclusion that the things we need to interact with are pretty hard to abstract out into something that would be generic across different agents. Everything we need to do in our case relates to how the agents use bridges and represent networks internally: linuxbridge has one bridge per Network, while OVS has a limited number of bridges playing different roles for all networks with internal segmentation. To look at the two things you mention: - "connect endpoint X to Y" : what we need to do is redirect the traffic destinated to the gateway of a Neutron network, to the thing that will do the MPLS forwarding for the right BGP VPN context (called VRF), in our case br-mpls (that could be done with an OVS table too) ; that action might be abstracted out to hide the details specific to OVS, but I'm not sure on how to name the destination in a way that would be agnostic to these details, and this is not really relevant to do until we have a relevant context in which the linuxbridge would pass packets to something doing MPLS forwarding (OVS is currently the
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
> On 30 Sep 2015, at 12:53, Miguel Angel Ajowrote: > > > > Ihar Hrachyshka wrote: >>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: >>> >>> Hi Ihar, >>> >>> Ihar Hrachyshka : > Miguel Angel Ajo : >> Do you have a rough idea of what operations you may need to do? > Right now, what bagpipe driver for networking-bgpvpn needs to interact > with is: > - int_br OVSBridge (read-only) > - tun_br OVSBridge (add patch port, add flows) > - patch_int_ofport port number (read-only) > - local_vlan_map dict (read-only) > - setup_entry_for_arp_reply method (called to add static ARP entries) > Sounds very tightly coupled to OVS agent. >> Please bear in mind, the extension interface will be available from >> different agent types >> (OVS, SR-IOV, [eventually LB]), so this interface you're talking about >> could also serve as >> a translation driver for the agents (where the translation is possible), >> I totally understand >> that most extensions are specific agent bound, and we must be able to >> identify >> the agent we're serving back exactly. > Yes, I do have this in mind, but what we've identified for now seems to > be OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. >>> I've been thinking about this, but would tend to reach the conclusion that >>> the things we need to interact with are pretty hard to abstract out into >>> something that would be generic across different agents. Everything we >>> need to do in our case relates to how the agents use bridges and represent >>> networks internally: linuxbridge has one bridge per Network, while OVS has >>> a limited number of bridges playing different roles for all networks with >>> internal segmentation. >>> >>> To look at the two things you mention: >>> - "connect endpoint X to Y" : what we need to do is redirect the traffic >>> destinated to the gateway of a Neutron network, to the thing that will do >>> the MPLS forwarding for the right BGP VPN context (called VRF), in our case >>> br-mpls (that could be done with an OVS table too) ; that action might be >>> abstracted out to hide the details specific to OVS, but I'm not sure on how >>> to name the destination in a way that would be agnostic to these details, >>> and this is not really relevant to do until we have a relevant context in >>> which the linuxbridge would pass packets to something doing MPLS forwarding >>> (OVS is currently the only option we support for MPLS forwarding, and it >>> does not really make sense to mix linuxbridge for Neutron L2/L3 and OVS for >>> MPLS) >>> - "determine segmentation id for a network": this is something really >>> OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and >>> does not rely on internal segmentation >>> >>> Completely abstracting out packet forwarding pipelines in OVS and >>> linuxbridge agents would possibly allow defining an interface that agent >>> extension could use without to know about anything specific to OVS or the >>> linuxbridge, but I believe this is a very significant taks to tackle. >> >> If you look for a clean way to integrate with reference agents, then it’s >> something that we should try to achieve. I agree it’s not an easy thing. >> >> Just an idea: can we have a resource for traffic forwarding, similar to >> security groups? I know folks are not ok with extending security groups API >> due to compatibility reasons, so maybe fwaas is the place to experiment with >> it. >> >>> Hopefully it will be acceptable to create an interface, even it exposes a >>> set of methods specific to the linuxbridge agent and a set of methods >>> specific to the OVS agent. That would mean that the agent extension that >>> can work in both contexts (not our case yet) would check the agent type >>> before using the first set or the second set. >> >> The assumption of the whole idea of l2 agent extensions is that they are >> agent agnostic. In case of QoS, we implemented a common QoS extension that >> can be plugged in any agent [1], and a set of backend drivers (atm it’s just >> sr-iov [2] and ovs [3]) that are selected based on the driver type argument >> passed into the extension manager [4][5]. Your extension could use similar >> approach to select the backend. >> >> [1]: >> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l2/extensions/qos.py#n169 >> [2]: >> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver.py >> [3]: >> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py >> [4]: >>
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Hi Irena, Irena Berezovsky : > I would like to second Kevin. This can be done in a similar way as ML2 Plugin passed plugin_context > to ML2 Extension Drivers: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910. Yes, this would be similar and could indeed be named agent_context . However, contrarily to ML2 plugin which provides a context when calling most driver methods, I don't think that here we would need a context to be passed at each call of an AgentCoreResourceExtension, providing a interface to hook to the agent at initialize seems enough to me. Thanks, -Thomas On Fri, Sep 25, 2015 at 11:57 AM, Kevin Benton> wrote: I think the 4th of the options you proposed would be the best. We don't want to give agents direct access to the agent object or else we will run the risk of breaking extensions all of the time during any kind of reorganization or refactoring. Having a well defined API in between will give us flexibility to move things around. On Fri, Sep 25, 2015 at 1:32 AM, > wrote: Hi everyone, (TL;DR: we would like an L2 agent extension to be able to call methods on the agent class, e.g. OVSAgent) In the networking-bgpvpn project, we need the reference driver to interact with the ML2 openvswitch agent with new RPCs to allow exchanging information with the BGP VPN implementation running on the compute nodes. We also need the OVS agent to setup specific things on the OVS bridges for MPLS traffic. To extend the agent behavior, we currently create a new agent by mimicking the main() in ovs_neutron_agent.py but instead of instantiating instantiate OVSAgent, with instantiate a class that overloads the OVSAgent class with the additional behavior we need [1] . This is really not the ideal way of extending the agent, and we would prefer using the L2 agent extension framework [2]. Using the L2 agent extension framework would work, but only partially: it would easily allos us to register our RPC consumers, but not to let us access to some datastructures/methods of the agent that we need to use: setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge objects to manipulate OVS ports. I've filled-in an RFE bug to track this issue [5]. We would like something like one of the following: 1) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access to the agent object (and thus let the extension call methods of the agent) by giving the agent as a parameter of the initialize method [4] 2) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access to the agent object (and thus let the extension call methods of the agent) by giving the agent as a parameter of a new setAgent method 3) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access only to specific/chosen methods on the agent object, for instance by giving a dict as a parameter of the initialize method [4], whose keys would be method names, and values would be pointer to these methods on the agent object 4) define a new interface with methods to access things inside the agent, this interface would be implemented by an object instantiated by the agent, and that the agent would pass to the extension manager, thus allowing the extension manager to passe the object to an extension through the initialize method of AgentCoreResourceExtension [4] Any feedback on these ideas...? Of course any other idea is welcome... For the sake of triggering reaction, the question could be rephrased as: if we submit a change doing (1) above, would it have a reasonable chance of merging ? -Thomas [1] https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py [2] https://review.openstack.org/#/c/195439/ [3] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 [4] https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 [5] https://bugs.launchpad.net/neutron/+bug/1499637 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) Sounds very tightly coupled to OVS agent. Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. I've been thinking about this, but would tend to reach the conclusion that the things we need to interact with are pretty hard to abstract out into something that would be generic across different agents. Everything we need to do in our case relates to how the agents use bridges and represent networks internally: linuxbridge has one bridge per Network, while OVS has a limited number of bridges playing different roles for all networks with internal segmentation. To look at the two things you mention: - "connect endpoint X to Y" : what we need to do is redirect the traffic destinated to the gateway of a Neutron network, to the thing that will do the MPLS forwarding for the right BGP VPN context (called VRF), in our case br-mpls (that could be done with an OVS table too) ; that action might be abstracted out to hide the details specific to OVS, but I'm not sure on how to name the destination in a way that would be agnostic to these details, and this is not really relevant to do until we have a relevant context in which the linuxbridge would pass packets to something doing MPLS forwarding (OVS is currently the only option we support for MPLS forwarding, and it does not really make sense to mix linuxbridge for Neutron L2/L3 and OVS for MPLS) - "determine segmentation id for a network": this is something really OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and does not rely on internal segmentation Completely abstracting out packet forwarding pipelines in OVS and linuxbridge agents would possibly allow defining an interface that agent extension could use without to know about anything specific to OVS or the linuxbridge, but I believe this is a very significant taks to tackle. If you look for a clean way to integrate with reference agents, then it’s something that we should try to achieve. I agree it’s not an easy thing. Just an idea: can we have a resource for traffic forwarding, similar to security groups? I know folks are not ok with extending security groups API due to compatibility reasons, so maybe fwaas is the place to experiment with it. Hopefully it will be acceptable to create an interface, even it exposes a set of methods specific to the linuxbridge agent and a set of methods specific to the OVS agent. That would mean that the agent extension that can work in both contexts (not our case yet) would check the agent type before using the first set or the second set. The assumption of the whole idea of l2 agent extensions is that they are agent agnostic. In case of QoS, we implemented a common QoS extension that can be plugged in any agent [1], and a set of backend drivers (atm it’s just sr-iov [2] and ovs [3]) that are selected based on the driver type argument passed into the extension manager [4][5]. Your extension could use similar approach to select the backend. [1]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l2/extensions/qos.py#n169 [2]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver.py [3]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py [4]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#n395 [5]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#n155 I disagree on the agent-agnostic thing. QoS extension for SR-IOV is totally not agnostic for OVS or LB, in the QoS case, it's just accidental that OVS & LB share common bridges now due to the OVS Hybrid implementation that
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) Sounds very tightly coupled to OVS agent. Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. I've been thinking about this, but would tend to reach the conclusion that the things we need to interact with are pretty hard to abstract out into something that would be generic across different agents. Everything we need to do in our case relates to how the agents use bridges and represent networks internally: linuxbridge has one bridge per Network, while OVS has a limited number of bridges playing different roles for all networks with internal segmentation. To look at the two things you mention: - "connect endpoint X to Y" : what we need to do is redirect the traffic destinated to the gateway of a Neutron network, to the thing that will do the MPLS forwarding for the right BGP VPN context (called VRF), in our case br-mpls (that could be done with an OVS table too) ; that action might be abstracted out to hide the details specific to OVS, but I'm not sure on how to name the destination in a way that would be agnostic to these details, and this is not really relevant to do until we have a relevant context in which the linuxbridge would pass packets to something doing MPLS forwarding (OVS is currently the only option we support for MPLS forwarding, and it does not really make sense to mix linuxbridge for Neutron L2/L3 and OVS for MPLS) - "determine segmentation id for a network": this is something really OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and does not rely on internal segmentation Completely abstracting out packet forwarding pipelines in OVS and linuxbridge agents would possibly allow defining an interface that agent extension could use without to know about anything specific to OVS or the linuxbridge, but I believe this is a very significant taks to tackle. Hopefully it will be acceptable to create an interface, even it exposes a set of methods specific to the linuxbridge agent and a set of methods specific to the OVS agent. That would mean that the agent extension that can work in both contexts (not our case yet) would check the agent type before using the first set or the second set. Does this approach make sense ? -Thomas _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ 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] How could an L2 agent extension access agent methods ?
> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: > > Hi Ihar, > > Ihar Hrachyshka : >>> Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? >>> Right now, what bagpipe driver for networking-bgpvpn needs to interact with >>> is: >>> - int_br OVSBridge (read-only) >>> - tun_br OVSBridge (add patch port, add flows) >>> - patch_int_ofport port number (read-only) >>> - local_vlan_map dict (read-only) >>> - setup_entry_for_arp_reply method (called to add static ARP entries) >>> >> Sounds very tightly coupled to OVS agent. > >> Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. >>> Yes, I do have this in mind, but what we've identified for now seems to be >>> OVS specific. >> Indeed it does. Maybe you can try to define the needed pieces in high level >> actions, not internal objects you need to access to. Like ‘- connect >> endpoint X to Y’, ‘determine segmentation id for a network’ etc. > > I've been thinking about this, but would tend to reach the conclusion that > the things we need to interact with are pretty hard to abstract out into > something that would be generic across different agents. Everything we need > to do in our case relates to how the agents use bridges and represent > networks internally: linuxbridge has one bridge per Network, while OVS has a > limited number of bridges playing different roles for all networks with > internal segmentation. > > To look at the two things you mention: > - "connect endpoint X to Y" : what we need to do is redirect the traffic > destinated to the gateway of a Neutron network, to the thing that will do the > MPLS forwarding for the right BGP VPN context (called VRF), in our case > br-mpls (that could be done with an OVS table too) ; that action might be > abstracted out to hide the details specific to OVS, but I'm not sure on how > to name the destination in a way that would be agnostic to these details, > and this is not really relevant to do until we have a relevant context in > which the linuxbridge would pass packets to something doing MPLS forwarding > (OVS is currently the only option we support for MPLS forwarding, and it does > not really make sense to mix linuxbridge for Neutron L2/L3 and OVS for MPLS) > - "determine segmentation id for a network": this is something really > OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and > does not rely on internal segmentation > > Completely abstracting out packet forwarding pipelines in OVS and linuxbridge > agents would possibly allow defining an interface that agent extension could > use without to know about anything specific to OVS or the linuxbridge, but I > believe this is a very significant taks to tackle. If you look for a clean way to integrate with reference agents, then it’s something that we should try to achieve. I agree it’s not an easy thing. Just an idea: can we have a resource for traffic forwarding, similar to security groups? I know folks are not ok with extending security groups API due to compatibility reasons, so maybe fwaas is the place to experiment with it. > > Hopefully it will be acceptable to create an interface, even it exposes a set > of methods specific to the linuxbridge agent and a set of methods specific to > the OVS agent. That would mean that the agent extension that can work in > both contexts (not our case yet) would check the agent type before using the > first set or the second set. The assumption of the whole idea of l2 agent extensions is that they are agent agnostic. In case of QoS, we implemented a common QoS extension that can be plugged in any agent [1], and a set of backend drivers (atm it’s just sr-iov [2] and ovs [3]) that are selected based on the driver type argument passed into the extension manager [4][5]. Your extension could use similar approach to select the backend. [1]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l2/extensions/qos.py#n169 [2]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver.py [3]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py [4]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#n395 [5]: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#n155 > > Does this approach make sense ? > > -Thomas > >
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
I would like to second Kevin. This can be done in a similar way as ML2 Plugin passed plugin_context to ML2 Extension Drivers: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910 . BR, Irena On Fri, Sep 25, 2015 at 11:57 AM, Kevin Bentonwrote: > I think the 4th of the options you proposed would be the best. We don't > want to give agents direct access to the agent object or else we will run > the risk of breaking extensions all of the time during any kind of > reorganization or refactoring. Having a well defined API in between will > give us flexibility to move things around. > > On Fri, Sep 25, 2015 at 1:32 AM, wrote: > >> Hi everyone, >> >> (TL;DR: we would like an L2 agent extension to be able to call methods on >> the agent class, e.g. OVSAgent) >> >> In the networking-bgpvpn project, we need the reference driver to >> interact with the ML2 openvswitch agent with new RPCs to allow exchanging >> information with the BGP VPN implementation running on the compute nodes. >> We also need the OVS agent to setup specific things on the OVS bridges for >> MPLS traffic. >> >> To extend the agent behavior, we currently create a new agent by >> mimicking the main() in ovs_neutron_agent.py but instead of instantiating >> instantiate OVSAgent, with instantiate a class that overloads the OVSAgent >> class with the additional behavior we need [1] . >> >> This is really not the ideal way of extending the agent, and we would >> prefer using the L2 agent extension framework [2]. >> >> Using the L2 agent extension framework would work, but only partially: it >> would easily allos us to register our RPC consumers, but not to let us >> access to some datastructures/methods of the agent that we need to use: >> setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge >> objects to manipulate OVS ports. >> >> I've filled-in an RFE bug to track this issue [5]. >> >> We would like something like one of the following: >> 1) augment the L2 agent extension interface (AgentCoreResourceExtension) >> to give access to the agent object (and thus let the extension call methods >> of the agent) by giving the agent as a parameter of the initialize method >> [4] >> 2) augment the L2 agent extension interface (AgentCoreResourceExtension) >> to give access to the agent object (and thus let the extension call methods >> of the agent) by giving the agent as a parameter of a new setAgent method >> 3) augment the L2 agent extension interface (AgentCoreResourceExtension) >> to give access only to specific/chosen methods on the agent object, for >> instance by giving a dict as a parameter of the initialize method [4], >> whose keys would be method names, and values would be pointer to these >> methods on the agent object >> 4) define a new interface with methods to access things inside the agent, >> this interface would be implemented by an object instantiated by the agent, >> and that the agent would pass to the extension manager, thus allowing the >> extension manager to passe the object to an extension through the >> initialize method of AgentCoreResourceExtension [4] >> >> Any feedback on these ideas...? >> Of course any other idea is welcome... >> >> For the sake of triggering reaction, the question could be rephrased as: >> if we submit a change doing (1) above, would it have a reasonable chance of >> merging ? >> >> -Thomas >> >> [1] >> https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py >> [2] https://review.openstack.org/#/c/195439/ >> [3] >> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 >> [4] >> https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 >> [5] https://bugs.launchpad.net/neutron/+bug/1499637 >> >> _ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
I think the 4th of the options you proposed would be the best. We don't want to give agents direct access to the agent object or else we will run the risk of breaking extensions all of the time during any kind of reorganization or refactoring. Having a well defined API in between will give us flexibility to move things around. On Fri, Sep 25, 2015 at 1:32 AM,wrote: > Hi everyone, > > (TL;DR: we would like an L2 agent extension to be able to call methods on > the agent class, e.g. OVSAgent) > > In the networking-bgpvpn project, we need the reference driver to interact > with the ML2 openvswitch agent with new RPCs to allow exchanging > information with the BGP VPN implementation running on the compute nodes. > We also need the OVS agent to setup specific things on the OVS bridges for > MPLS traffic. > > To extend the agent behavior, we currently create a new agent by mimicking > the main() in ovs_neutron_agent.py but instead of instantiating instantiate > OVSAgent, with instantiate a class that overloads the OVSAgent class with > the additional behavior we need [1] . > > This is really not the ideal way of extending the agent, and we would > prefer using the L2 agent extension framework [2]. > > Using the L2 agent extension framework would work, but only partially: it > would easily allos us to register our RPC consumers, but not to let us > access to some datastructures/methods of the agent that we need to use: > setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge > objects to manipulate OVS ports. > > I've filled-in an RFE bug to track this issue [5]. > > We would like something like one of the following: > 1) augment the L2 agent extension interface (AgentCoreResourceExtension) > to give access to the agent object (and thus let the extension call methods > of the agent) by giving the agent as a parameter of the initialize method > [4] > 2) augment the L2 agent extension interface (AgentCoreResourceExtension) > to give access to the agent object (and thus let the extension call methods > of the agent) by giving the agent as a parameter of a new setAgent method > 3) augment the L2 agent extension interface (AgentCoreResourceExtension) > to give access only to specific/chosen methods on the agent object, for > instance by giving a dict as a parameter of the initialize method [4], > whose keys would be method names, and values would be pointer to these > methods on the agent object > 4) define a new interface with methods to access things inside the agent, > this interface would be implemented by an object instantiated by the agent, > and that the agent would pass to the extension manager, thus allowing the > extension manager to passe the object to an extension through the > initialize method of AgentCoreResourceExtension [4] > > Any feedback on these ideas...? > Of course any other idea is welcome... > > For the sake of triggering reaction, the question could be rephrased as: > if we submit a change doing (1) above, would it have a reasonable chance of > merging ? > > -Thomas > > [1] > https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py > [2] https://review.openstack.org/#/c/195439/ > [3] > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 > [4] > https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 > [5] https://bugs.launchpad.net/neutron/+bug/1499637 > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > __ > 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 > > -- Kevin Benton
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Sorry, that should have said, "We don't want to give extensions direct access to the agent object..." On Fri, Sep 25, 2015 at 1:57 AM, Kevin Bentonwrote: > I think the 4th of the options you proposed would be the best. We don't > want to give agents direct access to the agent object or else we will run > the risk of breaking extensions all of the time during any kind of > reorganization or refactoring. Having a well defined API in between will > give us flexibility to move things around. > > On Fri, Sep 25, 2015 at 1:32 AM, wrote: > >> Hi everyone, >> >> (TL;DR: we would like an L2 agent extension to be able to call methods on >> the agent class, e.g. OVSAgent) >> >> In the networking-bgpvpn project, we need the reference driver to >> interact with the ML2 openvswitch agent with new RPCs to allow exchanging >> information with the BGP VPN implementation running on the compute nodes. >> We also need the OVS agent to setup specific things on the OVS bridges for >> MPLS traffic. >> >> To extend the agent behavior, we currently create a new agent by >> mimicking the main() in ovs_neutron_agent.py but instead of instantiating >> instantiate OVSAgent, with instantiate a class that overloads the OVSAgent >> class with the additional behavior we need [1] . >> >> This is really not the ideal way of extending the agent, and we would >> prefer using the L2 agent extension framework [2]. >> >> Using the L2 agent extension framework would work, but only partially: it >> would easily allos us to register our RPC consumers, but not to let us >> access to some datastructures/methods of the agent that we need to use: >> setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge >> objects to manipulate OVS ports. >> >> I've filled-in an RFE bug to track this issue [5]. >> >> We would like something like one of the following: >> 1) augment the L2 agent extension interface (AgentCoreResourceExtension) >> to give access to the agent object (and thus let the extension call methods >> of the agent) by giving the agent as a parameter of the initialize method >> [4] >> 2) augment the L2 agent extension interface (AgentCoreResourceExtension) >> to give access to the agent object (and thus let the extension call methods >> of the agent) by giving the agent as a parameter of a new setAgent method >> 3) augment the L2 agent extension interface (AgentCoreResourceExtension) >> to give access only to specific/chosen methods on the agent object, for >> instance by giving a dict as a parameter of the initialize method [4], >> whose keys would be method names, and values would be pointer to these >> methods on the agent object >> 4) define a new interface with methods to access things inside the agent, >> this interface would be implemented by an object instantiated by the agent, >> and that the agent would pass to the extension manager, thus allowing the >> extension manager to passe the object to an extension through the >> initialize method of AgentCoreResourceExtension [4] >> >> Any feedback on these ideas...? >> Of course any other idea is welcome... >> >> For the sake of triggering reaction, the question could be rephrased as: >> if we submit a change doing (1) above, would it have a reasonable chance of >> merging ? >> >> -Thomas >> >> [1] >> https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py >> [2] https://review.openstack.org/#/c/195439/ >> [3] >> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 >> [4] >> https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 >> [5] https://bugs.launchpad.net/neutron/+bug/1499637 >> >> _ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> >> __ >> OpenStack Development
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
Kevin, Miguel, I agree that (4) is what makes most sense. (more below) Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port number (read-only) - local_vlan_map dict (read-only) - setup_entry_for_arp_reply method (called to add static ARP entries) Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Yes, I do have this in mind, but what we've identified for now seems to be OVS specific. -Thomas Kevin Benton wrote: I think the 4th of the options you proposed would be the best. We don't want to give agents direct access to the agent object or else we will run the risk of breaking extensions all of the time during any kind of reorganization or refactoring. Having a well defined API in between will give us flexibility to move things around. On Fri, Sep 25, 2015 at 1:32 AM,wrote: Hi everyone, (TL;DR: we would like an L2 agent extension to be able to call methods on the agent class, e.g. OVSAgent) In the networking-bgpvpn project, we need the reference driver to interact with the ML2 openvswitch agent with new RPCs to allow exchanging information with the BGP VPN implementation running on the compute nodes. We also need the OVS agent to setup specific things on the OVS bridges for MPLS traffic. To extend the agent behavior, we currently create a new agent by mimicking the main() in ovs_neutron_agent.py but instead of instantiating instantiate OVSAgent, with instantiate a class that overloads the OVSAgent class with the additional behavior we need [1] . This is really not the ideal way of extending the agent, and we would prefer using the L2 agent extension framework [2]. Using the L2 agent extension framework would work, but only partially: it would easily allos us to register our RPC consumers, but not to let us access to some datastructures/methods of the agent that we need to use: setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge objects to manipulate OVS ports. I've filled-in an RFE bug to track this issue [5]. We would like something like one of the following: 1) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access to the agent object (and thus let the extension call methods of the agent) by giving the agent as a parameter of the initialize method [4] 2) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access to the agent object (and thus let the extension call methods of the agent) by giving the agent as a parameter of a new setAgent method 3) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access only to specific/chosen methods on the agent object, for instance by giving a dict as a parameter of the initialize method [4], whose keys would be method names, and values would be pointer to these methods on the agent object 4) define a new interface with methods to access things inside the agent, this interface would be implemented by an object instantiated by the agent, and that the agent would pass to the extension manager, thus allowing the extension manager to passe the object to an extension through the initialize method of AgentCoreResourceExtension [4] Any feedback on these ideas...? Of course any other idea is welcome... For the sake of triggering reaction, the question could be rephrased as: if we submit a change doing (1) above, would it have a reasonable chance of merging ? -Thomas [1] https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py [2] https://review.openstack.org/#/c/195439/ [3] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 [4] https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 [5] https://bugs.launchpad.net/neutron/+bug/1499637 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
> On 25 Sep 2015, at 14:37, thomas.mo...@orange.com wrote: > > Kevin, Miguel, > > I agree that (4) is what makes most sense. > (more below) > > Miguel Angel Ajo : >> Do you have a rough idea of what operations you may need to do? > > Right now, what bagpipe driver for networking-bgpvpn needs to interact with > is: > - int_br OVSBridge (read-only) > - tun_br OVSBridge (add patch port, add flows) > - patch_int_ofport port number (read-only) > - local_vlan_map dict (read-only) > - setup_entry_for_arp_reply method (called to add static ARP entries) > Sounds very tightly coupled to OVS agent. >> Please bear in mind, the extension interface will be available from >> different agent types >> (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could >> also serve as >> a translation driver for the agents (where the translation is possible), I >> totally understand >> that most extensions are specific agent bound, and we must be able to >> identify >> the agent we're serving back exactly. > > Yes, I do have this in mind, but what we've identified for now seems to be > OVS specific. Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc. Ihar signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] How could an L2 agent extension access agent methods ?
Yes, looks like option 4 is the best. We need an abstraction layer between extensions and agents, to make sure API makes sense for all AMQP based agents. Common agent framework that I think Sean side looks at [1] could partially define that agent interface for us. [1]: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z Ihar > On 25 Sep 2015, at 11:12, Miguel Angel Ajowrote: > > I didn't finish reading it, and was thinking about the same thing exactly. > > IMHO option 4th is the best. So we will be able to provide an interface where > stability > is controlled, where we can deprecate things in a controlled manner, and we > know what we > support and what we don't. > > Do you have a rough idea of what operations you may need to do? > > Please bear in mind, the extension interface will be available from different > agent types > (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could > also serve as > a translation driver for the agents (where the translation is possible), I > totally understand > that most extensions are specific agent bound, and we must be able to identify > the agent we're serving back exactly. > > > Best regards, > Miguel Ángel Ajo > > Kevin Benton wrote: >> I think the 4th of the options you proposed would be the best. We don't >> want to give agents direct access to the agent object or else we will run >> the risk of breaking extensions all of the time during any kind of >> reorganization or refactoring. Having a well defined API in between will >> give us flexibility to move things around. >> >> On Fri, Sep 25, 2015 at 1:32 AM, wrote: >> >>> Hi everyone, >>> >>> (TL;DR: we would like an L2 agent extension to be able to call methods on >>> the agent class, e.g. OVSAgent) >>> >>> In the networking-bgpvpn project, we need the reference driver to interact >>> with the ML2 openvswitch agent with new RPCs to allow exchanging >>> information with the BGP VPN implementation running on the compute nodes. >>> We also need the OVS agent to setup specific things on the OVS bridges for >>> MPLS traffic. >>> >>> To extend the agent behavior, we currently create a new agent by mimicking >>> the main() in ovs_neutron_agent.py but instead of instantiating instantiate >>> OVSAgent, with instantiate a class that overloads the OVSAgent class with >>> the additional behavior we need [1] . >>> >>> This is really not the ideal way of extending the agent, and we would >>> prefer using the L2 agent extension framework [2]. >>> >>> Using the L2 agent extension framework would work, but only partially: it >>> would easily allos us to register our RPC consumers, but not to let us >>> access to some datastructures/methods of the agent that we need to use: >>> setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge >>> objects to manipulate OVS ports. >>> >>> I've filled-in an RFE bug to track this issue [5]. >>> >>> We would like something like one of the following: >>> 1) augment the L2 agent extension interface (AgentCoreResourceExtension) >>> to give access to the agent object (and thus let the extension call methods >>> of the agent) by giving the agent as a parameter of the initialize method >>> [4] >>> 2) augment the L2 agent extension interface (AgentCoreResourceExtension) >>> to give access to the agent object (and thus let the extension call methods >>> of the agent) by giving the agent as a parameter of a new setAgent method >>> 3) augment the L2 agent extension interface (AgentCoreResourceExtension) >>> to give access only to specific/chosen methods on the agent object, for >>> instance by giving a dict as a parameter of the initialize method [4], >>> whose keys would be method names, and values would be pointer to these >>> methods on the agent object >>> 4) define a new interface with methods to access things inside the agent, >>> this interface would be implemented by an object instantiated by the agent, >>> and that the agent would pass to the extension manager, thus allowing the >>> extension manager to passe the object to an extension through the >>> initialize method of AgentCoreResourceExtension [4] >>> >>> Any feedback on these ideas...? >>> Of course any other idea is welcome... >>> >>> For the sake of triggering reaction, the question could be rephrased as: >>> if we submit a change doing (1) above, would it have a reasonable chance of >>> merging ? >>> >>> -Thomas >>> >>> [1] >>> https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py >>> [2] https://review.openstack.org/#/c/195439/ >>> [3] >>> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 >>> [4] >>>
Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
I didn't finish reading it, and was thinking about the same thing exactly. IMHO option 4th is the best. So we will be able to provide an interface where stability is controlled, where we can deprecate things in a controlled manner, and we know what we support and what we don't. Do you have a rough idea of what operations you may need to do? Please bear in mind, the extension interface will be available from different agent types (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could also serve as a translation driver for the agents (where the translation is possible), I totally understand that most extensions are specific agent bound, and we must be able to identify the agent we're serving back exactly. Best regards, Miguel Ángel Ajo Kevin Benton wrote: I think the 4th of the options you proposed would be the best. We don't want to give agents direct access to the agent object or else we will run the risk of breaking extensions all of the time during any kind of reorganization or refactoring. Having a well defined API in between will give us flexibility to move things around. On Fri, Sep 25, 2015 at 1:32 AM,wrote: Hi everyone, (TL;DR: we would like an L2 agent extension to be able to call methods on the agent class, e.g. OVSAgent) In the networking-bgpvpn project, we need the reference driver to interact with the ML2 openvswitch agent with new RPCs to allow exchanging information with the BGP VPN implementation running on the compute nodes. We also need the OVS agent to setup specific things on the OVS bridges for MPLS traffic. To extend the agent behavior, we currently create a new agent by mimicking the main() in ovs_neutron_agent.py but instead of instantiating instantiate OVSAgent, with instantiate a class that overloads the OVSAgent class with the additional behavior we need [1] . This is really not the ideal way of extending the agent, and we would prefer using the L2 agent extension framework [2]. Using the L2 agent extension framework would work, but only partially: it would easily allos us to register our RPC consumers, but not to let us access to some datastructures/methods of the agent that we need to use: setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge objects to manipulate OVS ports. I've filled-in an RFE bug to track this issue [5]. We would like something like one of the following: 1) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access to the agent object (and thus let the extension call methods of the agent) by giving the agent as a parameter of the initialize method [4] 2) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access to the agent object (and thus let the extension call methods of the agent) by giving the agent as a parameter of a new setAgent method 3) augment the L2 agent extension interface (AgentCoreResourceExtension) to give access only to specific/chosen methods on the agent object, for instance by giving a dict as a parameter of the initialize method [4], whose keys would be method names, and values would be pointer to these methods on the agent object 4) define a new interface with methods to access things inside the agent, this interface would be implemented by an object instantiated by the agent, and that the agent would pass to the extension manager, thus allowing the extension manager to passe the object to an extension through the initialize method of AgentCoreResourceExtension [4] Any feedback on these ideas...? Of course any other idea is welcome... For the sake of triggering reaction, the question could be rephrased as: if we submit a change doing (1) above, would it have a reasonable chance of merging ? -Thomas [1] https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py [2] https://review.openstack.org/#/c/195439/ [3] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 [4] https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 [5] https://bugs.launchpad.net/neutron/+bug/1499637 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed,