Hi Nachi, Sumit, <div><br></div><div>I've discussed service agent proposal with Eugene and Oleg - option 2-2 look the most preferable from architecture point-of-view. We'd like to help with its implementation, so to make it possible for VPNaaS and FWaaS to migrate to it in late H2. </div>
<div><br></div><div>Let's use <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-service-agent">https://blueprints.launchpad.net/quantum/+spec/quantum-service-agent</a> to track all work on service agents. We also plan to adapt LBaaS agent to agent scheduler framework, the corresponding bp is <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-scheduler">https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-scheduler</a></div>
<div><br></div><div>Thanks,</div><div>Ilya</div><div><br><div class="gmail_quote">2013/5/17 Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Summit<br>
<br>
Thank you for your comment.<br>
<br>
I have also talked with Mark at Quantum VPN meetings.<br>
Mark suggested we should start Option1 because it may take time to<br>
design Option2 and it may block progress of FWaaS and VPN.<br>
I agree with him.<br>
<br>
For first VPN implementation, we would like to extend L3agent class.<br>
then, let's migrate for option 2-2 in the middle or late H2 :)<br>
<br>
Thanks<br>
Nachi<br>
<br>
<br>
2013/5/16 Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com">sumitnaiksatam@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Nachi,<br>
><br>
> Thanks for posting your proposal on this. I agree, we will eventually<br>
> want to get to something similar to option 2-2. I also agree that we<br>
> probably need to do this in a phased manner.<br>
><br>
> To make immediate progress, could the option 2-1 be achieved by using<br>
> a mixin/inheritence approach? Each service would have it's own mixin,<br>
> which can in turn have the logic to load the appropriate driver. That<br>
> would probably result in the least amount of changes to the l3 agent<br>
> until we move towards something like option 2-2.<br>
><br>
> Thanks,<br>
> ~Sumit.<br>
><br>
> On Wed, May 15, 2013 at 10:56 AM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
>> Hi Kyle<br>
>><br>
>> I totally agree with you. In option 2-2, we have driver architecture<br>
>> and L3 functions should be also an driver.<br>
>> Option 2-1 is just for easy migration path.<br>
>><br>
>> Best<br>
>> Nachi<br>
>><br>
>> 2013/5/15 Kyle Mestery (kmestery) <<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>>:<br>
>>> On May 14, 2013, at 5:31 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
>>><br>
>>>> Hi Sumit and Networking folks<br>
>>>><br>
>>>> This is continuing discussion of this week openstack networking project.<br>
>>>> Multiple service is going to inject new function for Logical Router,<br>
>>>> however we are lacking framework for injecting functions for l3-agent<br>
>>>><br>
>>>> so I wrote some options in this slide.<br>
>>>><br>
>>>> <a href="https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.p" target="_blank">https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.p</a><br>

>>>><br>
>>>> I prefer Option2-1 for now, and migrate for option2-2 later in the slide.<br>
>>>><br>
>>> How does Option2-1 work when you want to provide the service functionality with something other than an L3 agent? For Option2-2, this becomes a bit clearer to me as you have the concept of "drivers" for the functionality. For routing functionality, keep in mind that Bob Melander is migrating more to this pluggable approach with his L3 changes for this blueprint:<br>

>>><br>
>>> <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin</a><br>
>>><br>
>>> Once that happens, there could be multiple L3 agents, or even L3 functionality without an agent, depending on how a plugin implements things. Perhaps this should be taken into consideration here as well.<br>

>>><br>
>>> Thanks,<br>
>>> Kyle<br>
>>><br>
>>>> Thanks<br>
>>>> Nachi<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>