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

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

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

On 12/17/2015 05:07 PM, Ihar Hrachyshka wrote: We may probably think of passing agent uuid into extensions to allow it to be used as a cookie for their flows, and make sure extensions are triggered before we reset obsolete flows in the agent. It may work. I would only want to see it as a

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

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

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

Hi Ihar, wow, good job!! Sorry for the very slow reply. I really like your proposal...some comments inline. On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote: Hi, Small update on the RFE. It was approved for Mitaka, assuming we come up with proper details upfront thru neutron-specs process. In

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

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

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

Hi, Small update on the RFE. It was approved for Mitaka, assuming we come up with proper details upfront thru neutron-specs process. In the meantime, we have found more use cases for flow management among features in development: QoS DSCP, also the new OF based firewall driver. Both

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

Thanks ihar! On Thu, Nov 19, 2015 at 2:32 PM, Ihar 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

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

UPD: now that we have some understanding what’s needed from l2 agent extension mechanism to cater for interested subprojects (and now that we see that probably the agent in focus right now is OVS only), we may move to RFE step. I reported the following RFE for the feature:

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

Hi Ihar, Ihar Hrachyshka : Reviving the thread. [...] (I appreciate if someone checks me on the following though): This is an excellent recap. I set up a new etherpad to collect feedback from subprojects [2]. I've filled in details for networking-bgpvpn. Please tell me if you need more

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

Reviving the thread. On the design summit session dedicated to agent and plugin extensions [1] the following was stated for l2 agent extensions (I appreciate if someone checks me on the following though): - current l2 agent extensions mechanism lacks insight into agent details like

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

> 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

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

Hi Irena, Irena Berezovsky : > I would like to second Kevin. This can be done in a similar way as ML2 Plugin passed plugin_context > to ML2 Extension Drivers: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910. Yes, this would be similar and could indeed

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

Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge

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

Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port

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

> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: > > Hi Ihar, > > Ihar Hrachyshka : >>> Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? >>> Right now, what bagpipe driver for networking-bgpvpn needs to interact with >>> is: >>> - int_br

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

I would like to second Kevin. This can be done in a similar way as ML2 Plugin passed plugin_context to ML2 Extension Drivers: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910 . BR, Irena On Fri, Sep 25, 2015 at 11:57 AM, Kevin Benton

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

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

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

I think the 4th of the options you proposed would be the best. We don't want to give agents direct access to the agent object or else we will run the risk of breaking extensions all of the time during any kind of reorganization or refactoring. Having a well defined API in between will give us

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

Sorry, that should have said, "We don't want to give extensions direct access to the agent object..." On Fri, Sep 25, 2015 at 1:57 AM, Kevin 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

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

Kevin, Miguel, I agree that (4) is what makes most sense. (more below) Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add

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

> On 25 Sep 2015, at 14:37, thomas.mo...@orange.com wrote: > > Kevin, Miguel, > > I agree that (4) is what makes most sense. > (more below) > > Miguel Angel Ajo : >> Do you have a rough idea of what operations you may need to do? > > Right now, what bagpipe driver for networking-bgpvpn needs

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

Yes, looks like option 4 is the best. We need an abstraction layer between extensions and agents, to make sure API makes sense for all AMQP based agents. Common agent framework that I think Sean side looks at [1] could partially define that agent interface for us. [1]:

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

I didn't finish reading it, and was thinking about the same thing exactly. IMHO option 4th is the best. So we will be able to provide an interface where stability is controlled, where we can deprecate things in a controlled manner, and we know what we support and what we don't. Do you have a