Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Armando M.]

Hi Henry,

Thanks for your input.


> No attention to argue on agent vs. agentless, built-in reference vs.
> external controller, Openstack is an open community. But, I just want
> to say that modularized agent re-factoring does make a lot of sense,
> while forcing customer to piggyback an extra SDN controller on their
> Cloud solution is not the only future direction of Neutron.
>

My main reference was with having the Kilo timeframe in mind. Once, we made
a clear demarcation between the various components, then they can develop
in isolation, which is very valuable IMO.
If enough critical mass gets behind an agent-based solution to control the
networking layer whichever it may be, I would be definitely okay with that,
but I don't think that is what Neutron should be concerned about, but
rather enabling these extra capabilities, the same way Nova does so with
hypervisors.

Cheers,
Armando
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[henry hly]

On Wed, Nov 26, 2014 at 12:14 AM, Mathieu Rohon  wrote:
> On Tue, Nov 25, 2014 at 9:59 AM, henry hly  wrote:
>> Hi Armando,
>>
>> Indeed agent-less solution like external controller is very
>> interesting, and in some certain cases it has advantage over agent
>> solution, e.g. software installation is prohibited on Compute Node.
>>
>> However, Neutron Agent has its irreplaceable benefits: multiple
>> backends support like SRIOV, macvtap, vhost-user snabbswitch, hybrid
>> vswitch solution like NIC offloading or VDP based TOR offloading...All
>> these backend can not be easily controlled by an remote OF controller.
>
> Moreover, this solution is tested by the gate (at least ovs), and is
> simpler for small deployments

Not only for small deployments, but also for large scale production
deployments :)

We have deployed more than 500 hosts in the customer production
cluster. Now we are doing some tuning on L2pop / SG / DHCPagent, after
that 1000 nodes cluster is expected to be supported. Also for vxlan
data plane performance, we upgraded the host kernel to 3.14 (with udp
tunnel gro/gso), and it has awful satisfied performance.

The customers have very positive feedback, they have never thought
that openstack bulit-in ovs backend can work so fine, without any help
from external controller platforms, or any special hardware
offloading.


>
>> Also considering DVR (maybe with upcoming FW for W-E), and Security
>> Group, W-E traffic control capability gap still exists between linux
>> stack and OF flowtable, whether features like advanced netfilter, or
>> performance for webserver app which incur huge concurrent sessions
>> (because of basic OF upcall model, the more complex flow rule, the
>> less megaflow aggregation might take effect)
>>
>> Thanks to L2pop and DVR, now many customer give the feedback that
>> Neutron has made great progressing, and already meet nearly all their
>> L2/L3 connectivity W-E control directing (The next big expectation is
>> N-S traffic directing like dynamic routing agent), without forcing
>> them to learn and integrate another huge platform like external SDN
>> controller.
>
> +100. Note that Dynamic routing is in progress.
>
>> No attention to argue on agent vs. agentless, built-in reference vs.
>> external controller, Openstack is an open community. But, I just want
>> to say that modularized agent re-factoring does make a lot of sense,
>> while forcing customer to piggyback an extra SDN controller on their
>> Cloud solution is not the only future direction of Neutron.
>>
>> Best Regard
>> Henry
>>
>> On Wed, Nov 19, 2014 at 5:45 AM, Armando M.  wrote:
>>> Hi Carl,
>>>
>>> Thanks for kicking this off. I am also willing to help as a core reviewer of
>>> blueprints and code
>>> submissions only.
>>>
>>> As for the ML2 agent, we all know that for historic reasons Neutron has
>>> grown to be not only a networking orchestration project but also a reference
>>> implementation that is resembling what some might call an SDN controller.
>>>
>>> I think that most of the Neutron folks realize that we need to move away
>>> from this model and rely on a strong open source SDN alternative; for these
>>> reasons, I don't think that pursuing an ML2 agent would be a path we should
>>> go down to anymore. It's time and energy that could be more effectively
>>> spent elsewhere, especially on the refactoring. Now if the refactoring
>>> effort ends up being labelled ML2 Agent, I would be okay with it, but my gut
>>> feeling tells me that any attempt at consolidating code to embrace more than
>>> one agent logic at once is gonna derail the major goal of paying down the so
>>> called agent debt.
>>>
>>> My 2c
>>> Armando
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Mathieu Rohon]

On Tue, Nov 25, 2014 at 9:59 AM, henry hly  wrote:
> Hi Armando,
>
> Indeed agent-less solution like external controller is very
> interesting, and in some certain cases it has advantage over agent
> solution, e.g. software installation is prohibited on Compute Node.
>
> However, Neutron Agent has its irreplaceable benefits: multiple
> backends support like SRIOV, macvtap, vhost-user snabbswitch, hybrid
> vswitch solution like NIC offloading or VDP based TOR offloading...All
> these backend can not be easily controlled by an remote OF controller.

Moreover, this solution is tested by the gate (at least ovs), and is
simpler for small deployments

> Also considering DVR (maybe with upcoming FW for W-E), and Security
> Group, W-E traffic control capability gap still exists between linux
> stack and OF flowtable, whether features like advanced netfilter, or
> performance for webserver app which incur huge concurrent sessions
> (because of basic OF upcall model, the more complex flow rule, the
> less megaflow aggregation might take effect)
>
> Thanks to L2pop and DVR, now many customer give the feedback that
> Neutron has made great progressing, and already meet nearly all their
> L2/L3 connectivity W-E control directing (The next big expectation is
> N-S traffic directing like dynamic routing agent), without forcing
> them to learn and integrate another huge platform like external SDN
> controller.

+100. Note that Dynamic routing is in progress.

> No attention to argue on agent vs. agentless, built-in reference vs.
> external controller, Openstack is an open community. But, I just want
> to say that modularized agent re-factoring does make a lot of sense,
> while forcing customer to piggyback an extra SDN controller on their
> Cloud solution is not the only future direction of Neutron.
>
> Best Regard
> Henry
>
> On Wed, Nov 19, 2014 at 5:45 AM, Armando M.  wrote:
>> Hi Carl,
>>
>> Thanks for kicking this off. I am also willing to help as a core reviewer of
>> blueprints and code
>> submissions only.
>>
>> As for the ML2 agent, we all know that for historic reasons Neutron has
>> grown to be not only a networking orchestration project but also a reference
>> implementation that is resembling what some might call an SDN controller.
>>
>> I think that most of the Neutron folks realize that we need to move away
>> from this model and rely on a strong open source SDN alternative; for these
>> reasons, I don't think that pursuing an ML2 agent would be a path we should
>> go down to anymore. It's time and energy that could be more effectively
>> spent elsewhere, especially on the refactoring. Now if the refactoring
>> effort ends up being labelled ML2 Agent, I would be okay with it, but my gut
>> feeling tells me that any attempt at consolidating code to embrace more than
>> one agent logic at once is gonna derail the major goal of paying down the so
>> called agent debt.
>>
>> My 2c
>> Armando
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[henry hly]

Hi Armando,

Indeed agent-less solution like external controller is very
interesting, and in some certain cases it has advantage over agent
solution, e.g. software installation is prohibited on Compute Node.

However, Neutron Agent has its irreplaceable benefits: multiple
backends support like SRIOV, macvtap, vhost-user snabbswitch, hybrid
vswitch solution like NIC offloading or VDP based TOR offloading...All
these backend can not be easily controlled by an remote OF controller.

Also considering DVR (maybe with upcoming FW for W-E), and Security
Group, W-E traffic control capability gap still exists between linux
stack and OF flowtable, whether features like advanced netfilter, or
performance for webserver app which incur huge concurrent sessions
(because of basic OF upcall model, the more complex flow rule, the
less megaflow aggregation might take effect)

Thanks to L2pop and DVR, now many customer give the feedback that
Neutron has made great progressing, and already meet nearly all their
L2/L3 connectivity W-E control directing (The next big expectation is
N-S traffic directing like dynamic routing agent), without forcing
them to learn and integrate another huge platform like external SDN
controller.

No attention to argue on agent vs. agentless, built-in reference vs.
external controller, Openstack is an open community. But, I just want
to say that modularized agent re-factoring does make a lot of sense,
while forcing customer to piggyback an extra SDN controller on their
Cloud solution is not the only future direction of Neutron.

Best Regard
Henry

On Wed, Nov 19, 2014 at 5:45 AM, Armando M.  wrote:
> Hi Carl,
>
> Thanks for kicking this off. I am also willing to help as a core reviewer of
> blueprints and code
> submissions only.
>
> As for the ML2 agent, we all know that for historic reasons Neutron has
> grown to be not only a networking orchestration project but also a reference
> implementation that is resembling what some might call an SDN controller.
>
> I think that most of the Neutron folks realize that we need to move away
> from this model and rely on a strong open source SDN alternative; for these
> reasons, I don't think that pursuing an ML2 agent would be a path we should
> go down to anymore. It's time and energy that could be more effectively
> spent elsewhere, especially on the refactoring. Now if the refactoring
> effort ends up being labelled ML2 Agent, I would be okay with it, but my gut
> feeling tells me that any attempt at consolidating code to embrace more than
> one agent logic at once is gonna derail the major goal of paying down the so
> called agent debt.
>
> My 2c
> Armando
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[marios]

On 19/11/14 11:34, Rossella Sblendido wrote:
> My name is also on the etherpad, I'd like to work on improving RPC and
> ovslib. I am willing to take care of the BP, if somebody else is
> interested we can do it together.

sure I can help - (let's sync up on irc to split out the sections and
get an etherpad going which we can then just paste into a spec - we can
just use the l3 one as a template?)

thanks, marios

> 
> cheers,
> 
> Rossella
> 
> 
> On 11/19/2014 12:01 AM, Kevin Benton wrote:
>> My name is already on the etherpad in the RPC section, but I'll
>> reiterate here that I'm very interested in optimizing a lot of the
>> expensive ongoing communication between the L2 agent and the server on
>> the message bus.
>>
>> On Tue, Nov 18, 2014 at 9:12 AM, Carl Baldwin > > wrote:
>>
>> At the recent summit, we held a session about debt repayment in the
>> Neutron agents [1].  Some work was identified for the L2 agent.  We
>> had a discussion in the Neutron meeting today about bootstrapping that
>> work.
>>
>> The first order of business will be to generate a blueprint
>> specification for the work similar, in purpose, to the one that is
>> under discussion for the L3 agent [3].  I personally am at or over
>> capacity for BP writing this cycle.  We need a volunteer to take this
>> on coordinating with others who have been identified on the etherpad
>> for L2 agent work (you know who you are) and other volunteers who have
>> yet to be identified.
>>
>> This "task force" will use the weekly Neutron meeting, the ML, and IRC
>> to coordinate efforts.  But first, we need to bootstrap the task
>> force.  If you plan to participate, please reply to this email and
>> describe how you will contribute, especially if you are willing to be
>> the lead author of a BP.  I will reconcile this with the etherpad to
>> see where gaps have been left.
>>
>> I am planning to contribute as a core reviewer of blueprints and code
>> submissions only.
>>
>> Carl
>>
>> [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
>> [2]
>> 
>> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html
>> [3] https://review.openstack.org/#/c/131535/
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> -- 
>> Kevin Benton
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Rossella Sblendido]

My name is also on the etherpad, I'd like to work on improving RPC and
ovslib. I am willing to take care of the BP, if somebody else is
interested we can do it together.

cheers,

Rossella


On 11/19/2014 12:01 AM, Kevin Benton wrote:
> My name is already on the etherpad in the RPC section, but I'll
> reiterate here that I'm very interested in optimizing a lot of the
> expensive ongoing communication between the L2 agent and the server on
> the message bus.
> 
> On Tue, Nov 18, 2014 at 9:12 AM, Carl Baldwin  > wrote:
> 
> At the recent summit, we held a session about debt repayment in the
> Neutron agents [1].  Some work was identified for the L2 agent.  We
> had a discussion in the Neutron meeting today about bootstrapping that
> work.
> 
> The first order of business will be to generate a blueprint
> specification for the work similar, in purpose, to the one that is
> under discussion for the L3 agent [3].  I personally am at or over
> capacity for BP writing this cycle.  We need a volunteer to take this
> on coordinating with others who have been identified on the etherpad
> for L2 agent work (you know who you are) and other volunteers who have
> yet to be identified.
> 
> This "task force" will use the weekly Neutron meeting, the ML, and IRC
> to coordinate efforts.  But first, we need to bootstrap the task
> force.  If you plan to participate, please reply to this email and
> describe how you will contribute, especially if you are willing to be
> the lead author of a BP.  I will reconcile this with the etherpad to
> see where gaps have been left.
> 
> I am planning to contribute as a core reviewer of blueprints and code
> submissions only.
> 
> Carl
> 
> [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
> [2]
> 
> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html
> [3] https://review.openstack.org/#/c/131535/
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Kevin Benton
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Kevin Benton]

My name is already on the etherpad in the RPC section, but I'll reiterate
here that I'm very interested in optimizing a lot of the expensive ongoing
communication between the L2 agent and the server on the message bus.

On Tue, Nov 18, 2014 at 9:12 AM, Carl Baldwin  wrote:

> At the recent summit, we held a session about debt repayment in the
> Neutron agents [1].  Some work was identified for the L2 agent.  We
> had a discussion in the Neutron meeting today about bootstrapping that
> work.
>
> The first order of business will be to generate a blueprint
> specification for the work similar, in purpose, to the one that is
> under discussion for the L3 agent [3].  I personally am at or over
> capacity for BP writing this cycle.  We need a volunteer to take this
> on coordinating with others who have been identified on the etherpad
> for L2 agent work (you know who you are) and other volunteers who have
> yet to be identified.
>
> This "task force" will use the weekly Neutron meeting, the ML, and IRC
> to coordinate efforts.  But first, we need to bootstrap the task
> force.  If you plan to participate, please reply to this email and
> describe how you will contribute, especially if you are willing to be
> the lead author of a BP.  I will reconcile this with the etherpad to
> see where gaps have been left.
>
> I am planning to contribute as a core reviewer of blueprints and code
> submissions only.
>
> Carl
>
> [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
> [2]
> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html
> [3] https://review.openstack.org/#/c/131535/
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Mohammad Banikazemi]

Salvatore Orlando  wrote on 11/18/2014 04:15:35 PM:

> From: Salvatore Orlando 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 11/18/2014 04:19 PM
> Subject: Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping
> an L2 agent debt repayment task force
>
> I think we should also get rid of some nonsenses in the way events
> are processed by the l2 agent. Carl did something similar for the l3
agent.
> In the past release cycle I put some patches to avoid event
> starvation or to prevent the same event to be processed multiple
> times, but I did not address the root cause of the issue.
>
> This is probably already in the etherpad under the bullet "ovsdb
> monitor improvements". It seems the current assignee is Terry, but I
> guess nobody would mind If I submit a spec for it just to assess
> what are the point of conflicts with other tasks, and then maybe
> either I or Terry do the actual work.
>
> Regarding the modular l2 agent, I think that was the one item for
> which the consensus was to defer. Not because it wasn't deemed
> important. I think the concern here was that it was a major
> refactoring which pretty much would have blocked all other
> activities. But I am happy to reconsider or find a strategy to
> ensure the modular l2 agent could fit into kilo plans.
>


I was not aware of this development regarding Modular L2 Agent. It wasn't
obvious from the etherpad but that is understandable. There is so much you
can capture in an etherpad. Thanks for clarifying it promptly.



> Salvatore
>
> On 18 November 2014 19:32, Mohammad Banikazemi  wrote:
> I had done some work on looking at L2 agents and identifying how we
> may want to go about creating a Modular L2 Agent framework to make
> the agent code more modular, avoid code replication across multiple
> L2 agents, and to make adding new features and writing new agents
> (if/when necessary) easier. I will be happy to take a stab at
> writing the blueprint/spec based on that work and what is specified
> in the etherpad [1].
>
> I had to take a few weeks off from work and therefore had to miss
> the Summit; This happened right around the time that "paying our
> technical debts" was becoming a common phrase in Neutron (for good
> reasons) and from what I can gather from the etherpad [1] the scope
> for this effort may have expanded and there are others who have
> volunteered to work on various aspects of this effort. So, if there
> are others who want to start the "task force" by writing this
> blueprint/spec, that is perfectly fine with me. If not, I will be
> happy to get that started.
>
> Best,
>
> Mohammad (banix)
>
>
>
> [image removed] Carl Baldwin ---11/18/2014 12:19:00 PM---At the
> recent summit, we held a session about debt repayment in the Neutron
> agents [1].  Some work w
>
> From: Carl Baldwin 
> To: OpenStack Development Mailing List

> Date: 11/18/2014 12:19 PM
> Subject: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an
> L2 agent debt repayment task force
>
>
>
>
> At the recent summit, we held a session about debt repayment in the
> Neutron agents [1].  Some work was identified for the L2 agent.  We
> had a discussion in the Neutron meeting today about bootstrapping that
> work.
>
> The first order of business will be to generate a blueprint
> specification for the work similar, in purpose, to the one that is
> under discussion for the L3 agent [3].  I personally am at or over
> capacity for BP writing this cycle.  We need a volunteer to take this
> on coordinating with others who have been identified on the etherpad
> for L2 agent work (you know who you are) and other volunteers who have
> yet to be identified.
>
> This "task force" will use the weekly Neutron meeting, the ML, and IRC
> to coordinate efforts.  But first, we need to bootstrap the task
> force.  If you plan to participate, please reply to this email and
> describe how you will contribute, especially if you are willing to be
> the lead author of a BP.  I will reconcile this with the etherpad to
> see where gaps have been left.
>
> I am planning to contribute as a core reviewer of blueprints and code
> submissions only.
>
> Carl
>
> [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
> [2] http://eavesdrop.openstack.org/meetings/networking/2014/
> networking.2014-11-18-14.02.html
> [3] https://review.openstack.org/#/c/131535/
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

&

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Armando M.]

Hi Carl,

Thanks for kicking this off. I am also willing to help as a core reviewer
of blueprints and code
submissions only.

As for the ML2 agent, we all know that for historic reasons Neutron has
grown to be not only a networking orchestration project but also a
reference implementation that is resembling what some might call an SDN
controller.

I think that most of the Neutron folks realize that we need to move away
from this model and rely on a strong open source SDN alternative; for these
reasons, I don't think that pursuing an ML2 agent would be a path we should
go down to anymore. It's time and energy that could be more effectively
spent elsewhere, especially on the refactoring. Now if the refactoring
effort ends up being labelled ML2 Agent, I would be okay with it, but my
gut feeling tells me that any attempt at consolidating code to embrace more
than one agent logic at once is gonna derail the major goal of paying down
the so called agent debt.

My 2c
Armando
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Salvatore Orlando]

I think we should also get rid of some nonsenses in the way events are
processed by the l2 agent. Carl did something similar for the l3 agent.
In the past release cycle I put some patches to avoid event starvation or
to prevent the same event to be processed multiple times, but I did not
address the root cause of the issue.

This is probably already in the etherpad under the bullet "ovsdb monitor
improvements". It seems the current assignee is Terry, but I guess nobody
would mind If I submit a spec for it just to assess what are the point of
conflicts with other tasks, and then maybe either I or Terry do the actual
work.

Regarding the modular l2 agent, I think that was the one item for which the
consensus was to defer. Not because it wasn't deemed important. I think the
concern here was that it was a major refactoring which pretty much would
have blocked all other activities. But I am happy to reconsider or find a
strategy to ensure the modular l2 agent could fit into kilo plans.

Salvatore

On 18 November 2014 19:32, Mohammad Banikazemi  wrote:

> I had done some work on looking at L2 agents and identifying how we may
> want to go about creating a Modular L2 Agent framework to make the agent
> code more modular, avoid code replication across multiple L2 agents, and to
> make adding new features and writing new agents (if/when necessary) easier.
> I will be happy to take a stab at writing the blueprint/spec based on that
> work and what is specified in the etherpad [1].
>
> I had to take a few weeks off from work and therefore had to miss the
> Summit; This happened right around the time that "paying our technical
> debts" was becoming a common phrase in Neutron (for good reasons) and from
> what I can gather from the etherpad [1] the scope for this effort may have
> expanded and there are others who have volunteered to work on various
> aspects of this effort. So, if there are others who want to start the "task
> force" by writing this blueprint/spec, that is perfectly fine with me. If
> not, I will be happy to get that started.
>
> Best,
>
> Mohammad (banix)
>
>
>
> [image: Inactive hide details for Carl Baldwin ---11/18/2014 12:19:00
> PM---At the recent summit, we held a session about debt repayment]Carl
> Baldwin ---11/18/2014 12:19:00 PM---At the recent summit, we held a session
> about debt repayment in the Neutron agents [1].  Some work w
>
> From: Carl Baldwin 
> To: OpenStack Development Mailing List 
> Date: 11/18/2014 12:19 PM
> Subject: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2
> agent debt repayment task force
> --
>
>
>
> At the recent summit, we held a session about debt repayment in the
> Neutron agents [1].  Some work was identified for the L2 agent.  We
> had a discussion in the Neutron meeting today about bootstrapping that
> work.
>
> The first order of business will be to generate a blueprint
> specification for the work similar, in purpose, to the one that is
> under discussion for the L3 agent [3].  I personally am at or over
> capacity for BP writing this cycle.  We need a volunteer to take this
> on coordinating with others who have been identified on the etherpad
> for L2 agent work (you know who you are) and other volunteers who have
> yet to be identified.
>
> This "task force" will use the weekly Neutron meeting, the ML, and IRC
> to coordinate efforts.  But first, we need to bootstrap the task
> force.  If you plan to participate, please reply to this email and
> describe how you will contribute, especially if you are willing to be
> the lead author of a BP.  I will reconcile this with the etherpad to
> see where gaps have been left.
>
> I am planning to contribute as a core reviewer of blueprints and code
> submissions only.
>
> Carl
>
> [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
> [2]
> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html
> [3] https://review.openstack.org/#/c/131535/
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Mohammad Banikazemi]

I had done some work on looking at L2 agents and identifying how we may
want to go about creating a Modular L2 Agent framework to make the agent
code more modular, avoid code replication across multiple L2 agents, and to
make adding new features and writing new agents (if/when necessary) easier.
I will be happy to take a stab at writing the blueprint/spec based on that
work and what is specified in the etherpad [1].

I had to take a few weeks off from work and therefore had to miss the
Summit; This happened right around the time that "paying our technical
debts" was becoming a common phrase in Neutron (for good reasons) and from
what I can gather from the etherpad [1] the scope for this effort may have
expanded and there are others who have volunteered to work on various
aspects of this effort. So, if there are others who want to start the "task
force" by writing this blueprint/spec, that is perfectly fine with me. If
not, I will be happy to get that started.

Best,

Mohammad (banix)





From:   Carl Baldwin 
To: OpenStack Development Mailing List

Date:   11/18/2014 12:19 PM
Subject:[openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2
agent debt repayment task force



At the recent summit, we held a session about debt repayment in the
Neutron agents [1].  Some work was identified for the L2 agent.  We
had a discussion in the Neutron meeting today about bootstrapping that
work.

The first order of business will be to generate a blueprint
specification for the work similar, in purpose, to the one that is
under discussion for the L3 agent [3].  I personally am at or over
capacity for BP writing this cycle.  We need a volunteer to take this
on coordinating with others who have been identified on the etherpad
for L2 agent work (you know who you are) and other volunteers who have
yet to be identified.

This "task force" will use the weekly Neutron meeting, the ML, and IRC
to coordinate efforts.  But first, we need to bootstrap the task
force.  If you plan to participate, please reply to this email and
describe how you will contribute, especially if you are willing to be
the lead author of a BP.  I will reconcile this with the etherpad to
see where gaps have been left.

I am planning to contribute as a core reviewer of blueprints and code
submissions only.

Carl

[1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
[2]
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html

[3] https://review.openstack.org/#/c/131535/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev