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 o
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, as
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 tempo
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
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
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 develo
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 t
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 autho
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
> R
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.laun
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 i
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 bridge
> 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?
> Rig
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 (
> 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 OVSBridg
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
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 nu
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
> 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 t
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 pa
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
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
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 flexi
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
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 impl
25 matches
Mail list logo
