<div dir="ltr">Hi Nachi,<div><br></div><div>I agree on the future plan.</div><div>However, dynamic loading/unloading of provider drivers will require additional code in service plugins, I'm not sure this will be fully supported in Havana (while I'm totally agree on implementing it)</div>
<div><br></div><div>Thanks,</div><div style>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 3:40 AM, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eugene<br>
<br>
It still not make sense for me to store static configuration on the DB<br>
just for easy implementation.<br>
However if the service type will support creation and deletion REST<br>
api in future, I would like to approve this patch<br>
as a first step of it.<br>
You answered "I think it's doable but I'd still consider current<br>
implementation as a first step - enikanorov. "<br>
in the googled docs. so I believe we are in the same boat now.<br>
<br>
I wanna make it clear future work.<br>
<br>
- Service Type REST API (for admin) will add supports<br>
  - Ceate Service Type<br>
  - Delete Service Type<br>
 -  Each driver users will lazy load the library if it is not loaded.<br>
    (may be this should be implemented on service side such as FW, LBaaS,VPN)<br>
<br>
- Remove service type configuration from conf<br>
<br>
Is this OK for you guys?<br>
<br>
Thanks<br>
Nachi<br>
<br>
<br>
2013/7/8 Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>:<br>
<div><div class="h5">> Hi neutron folks,<br>
><br>
> There has been a discussion around this patch<br>
> <a href="https://review.openstack.org/#/c/29750/" target="_blank">https://review.openstack.org/#/c/29750/</a> that introduces configuration<br>
> options and db table for storing service providers.<br>
><br>
> The discussion is about whether we should store configuration in the db or<br>
> not.<br>
> The brief of discussion has been saved here:<br>
> <a href="https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gefc32ecf_00" target="_blank">https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gefc32ecf_00</a><br>

> Please share your thoughts on this.<br>
><br>
> While we may continue to discuss the best approach to this, I'd like to see<br>
> the patch to be committed first (it seems to be ready) as there are other<br>
> features depending on it (NSX distributed router, lbaas, fwaas and vpnaas<br>
> possibly).<br>
><br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
</div></div>> _______________________________________________<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>
</blockquote></div><br></div>