Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
On Tue, Nov 25, 2014 at 9:59 AM, henry hly henry4...@gmail.com 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. arma...@gmail.com 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
On Wed, Nov 26, 2014 at 12:14 AM, Mathieu Rohon mathieu.ro...@gmail.com wrote: On Tue, Nov 25, 2014 at 9:59 AM, henry hly henry4...@gmail.com 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. arma...@gmail.com 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
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 c...@ecbaldwin.net mailto:c...@ecbaldwin.net 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 mailto: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
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 c...@ecbaldwin.net mailto:c...@ecbaldwin.net 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 mailto: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
[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
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 c...@ecbaldwin.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org 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
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. Salvatore On 18 November 2014 19:32, Mohammad Banikazemi m...@us.ibm.com 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 c...@ecbaldwin.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org 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
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 sorla...@nicira.com wrote on 11/18/2014 04:15:35 PM: From: Salvatore Orlando sorla...@nicira.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 m...@us.ibm.com 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 c...@ecbaldwin.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org 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
Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
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 c...@ecbaldwin.net 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
