<div dir="ltr">Some comments inline.<div><br></div><div>Salvatore<br><div class="gmail_extra"><br><br><div class="gmail_quote">On 9 July 2013 21:58, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nachi, <div><br></div><div>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></blockquote><div><br></div><div style>Besides, the real issue with this approach is that neutron would be lending itself to any sort of security exploit. I am not a security expert, so feel free to disagree if you want.</div>
<div style>I would just prefer to not see dynamic loading of python modules of values which are stored in the db; not in this release, not in the next one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>I think what really matters is how service providers are referenced from other resources.</div><div><br></div><div>1) From logic perspective service provider could be referenced by (service_type, name) as it's unique primary key.</div>
<div>2) From data normalization perspective it's better (and more convenient) to have an unique ID in resource provider model.</div></div></blockquote><div><br></div><div style>Adding another primary key were you already identified a couple of attributes which are a primary key is actually, from what I recall from my studies, de-normalization.</div>
<div style>Sorry, this was just pedant me talking. Feel free to ignore.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Obviously having ID works for DB implementation and doesn't work for in-memory implementation.</div>
<div>In other words, we can't use ID if we go with in-memory implementation.</div></div></blockquote><div><br></div><div style>You could, but it would not make a lot of sense; and you would have to store those ids somewhere anyway; so - no it's not a good idea.</div>
<div style><br></div><div style>When you associate an instance of a service to a provider, you might think that the fact that they key is (type, name) will force you to use two attributes. This would be true if you think about the corresponding E-R model. However, in the case of the APIs we're dealing with, the resource type itself identifies the first bit of the (type, name) pair. So one might as well associate only the service provider name to the service instance.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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>4) From CLI perspective it's more convenient if resource has ID, it's a common way of specifying resource.</div></div></blockquote><div><br></div><div style>We already clarified that for referencing items in the CLI (or horizon) we can use either name or id. It's a consolidated practice in both of them.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>5) From user perspective it's more convenient to specify the name of service provider.<br>
</div><div>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><br></div><div>Resuming all this I see significant benefits of using ID (and hence, db implementation) over not using it.</div>
<div>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></blockquote><div><br></div><div style>As Mark has rightly pointed out, it's generally not a great idea to store configuration data in the db.</div>
<div style>However in this case it is worth mentioning that the data in the db is exactly the same as the data in the config files.</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>DB storage offers better integration with other objects stored in db, and saves some code lines doing stuff which DB normally does.</div>
<div>That lines will stack up in case we add more objects (like service offerings) on top of in-memory storage.</div></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div><div>
<br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><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" target="_blank">enikanorov@mirantis.com</a>>:<br>
<div><div>> 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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div><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></blockquote></div><br></div></div></div>