<div dir="ltr">Nachi, <div><br></div><div style>I think that dynamic loading/preloaded modules/REST api analogs of nova flavor is a bit too forward looking in comparison to what I'm trying to solve right now with existing patch.</div>
<div style><br></div><div style>I think what really matters is how service providers are referenced from other resources.</div><div style><br></div><div style>1) From logic perspective service provider could be referenced by (service_type, name) as it's unique primary key.</div>
<div style>2) From data normalization perspective it's better (and more convenient) to have an unique ID in resource provider model.</div><div style>Obviously having ID works for DB implementation and doesn't work for in-memory implementation.</div>
<div style>In other words, we can't use ID if we go with in-memory implementation.</div><div style>3) From data modelling perspective it's better to have ID in service provider model as referencing models will be simpler and easier to maintain.</div>
<div style>4) From CLI perspective it's more convenient if resource has ID, it's a common way of specifying resource.</div><div style>5) From user perspective it's more convenient to specify the name of service provider.<br>
</div><div style>But that is usually solved either by Horizon or by cli, like it's done for networks/subnets where name of the object is specified.</div><div style><br></div><div style>Resuming all this I see significant benefits of using ID (and hence, db implementation) over not using it.</div>
<div style>Also, I don't think storing immutable data in db is any kind of a bad design: it's just a storage anyway. </div><div style>DB storage offers better integration with other objects stored in db, and saves some code lines doing stuff which DB normally does.</div>
<div style>That lines will stack up in case we add more objects (like service offerings) on top of in-memory storage.</div><div style><br></div><div style>Thanks,</div><div style>Eugene.</div><div style><br></div><div style>
<br></div><div style><br></div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 11:00 PM, 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>
I agree for dynamic loading is difficult to implement.<br>
(mainly for security perspective)<br>
<br>
Salvatore looks clearly for no for dynamic loading.<br>
<br>
So I added another option.<br>
how about have list of preloaded module in the conf?<br>
and setup service type from REST API such as nova flavor api<br>
<br>
<a href="https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00" target="_blank">https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00</a><br>

<br>
NOTE: I updated the style of doc<br>
<br>
Best<br>
Nachi<br>
<br>
<br>
2013/7/9 Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Nachi,<br>
><br>
> I agree on the future plan.<br>
> However, dynamic loading/unloading of provider drivers will require<br>
> additional code in service plugins, I'm not sure this will be fully<br>
> supported in Havana (while I'm totally agree on implementing it)<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
> On Tue, Jul 9, 2013 at 3:40 AM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
>><br>
>> 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,<br>
>> 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>
>> > 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<br>
>> > or<br>
>> > not.<br>
>> > The brief of discussion has been saved here:<br>
>> ><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<br>
>> > see<br>
>> > the patch to be committed first (it seems to be ready) as there are<br>
>> > other<br>
>> > features depending on it (NSX distributed router, lbaas, fwaas and<br>
>> > vpnaas<br>
>> > possibly).<br>
>> ><br>
>> ><br>
>> > Thanks,<br>
>> > Eugene.<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>
><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>
</div></div></blockquote></div><br></div>