Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Rossella Sblendido  wrote:




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.


So the first piece to allow extensions to play nice with OVS agent graceful  
restart is uploaded, namely the spec: https://review.openstack.org/263819


We’ll consider the major flow table rework as proposed in the thread as a  
second phase with a separate spec based on top of the one I pasted. The  
rationale of the staged approach is to unblock folks that need to set their  
flows. The rework will obviously take some time and probably will span to  
the next cycle.


I think David was going to test the approach similar to what is proposed in  
the spec, to see whether it would be enough to make restarts graceful for  
extensions; I will also work on implementation more in line with the  
proposal in parallel with spec approval to boost things.


Ihar

__
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 Sblendido]

On 12/17/2015 04:45 PM, Ihar Hrachyshka wrote:

Rossella Sblendido  wrote:


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 more about this...It wo

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Rossella Sblendido]

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 ?

[Ihar Hrachyshka]

Takashi Yamamoto  wrote:


hi,

On Fri, Dec 4, 2015 at 12:46 AM, 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 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.


Could be. If we realize it, we will build on top of general agent API  
framework. The rest of proposal talks about flow management though, and if  
we feel some use cases can be covered with just patch ports, no flows  
involved, we can split efforts and push some stub agent API that can be  
evolved in parallel for two things.





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)


Lately I started to think that allowing all types of rules in extension  
tables is not such a bad idea, as long as the agent is the entity managing  
cookies, not extensions (for disruption-less agent restarts).




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 f

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Rossella Sblendido  wrote:


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 with the same frame pie

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Takashi Yamamoto]

hi,

On Fri, Dec 4, 2015 at 12:46 AM, 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 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 it’s not sane. :)

i 

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Rossella Sblendido]

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 pr

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

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 Rohon  wrote:


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 the following RFE for the feature:


https://bug

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Mathieu Rohon]

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 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 generic across different agents.  Everything
>> we need to do in our case relates t

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

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 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 do

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Thomas Morin]

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 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 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 

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

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 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 forwardin

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

> 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 
>> 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/ne

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Miguel Angel Ajo]

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 ?

[Ihar Hrachyshka]

> 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 ?

[thomas.morin]

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, mailto:thomas.mo...@orange.com>> 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
   

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[thomas.morin]

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 ?

[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
.

BR,
Irena

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 
>> 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.
>>
>>
>> __

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

> 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 ?

[thomas.morin]

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 decline toute responsabilite s

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

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 Ajo  wrote:
> 
> 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.n

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Miguel Angel Ajo]

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, used or copied without autho

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Kevin Benton]

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
__
OpenStack Development 

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Kevin Benton]

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 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, 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)
>> Uns

[openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[thomas.morin]

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