<div dir="ltr">Folks,<div><br></div><div style>I have put initial in-memory implementation of service providers on review.</div><div style><br></div><div style>On of the 'hacks' I had to do is decoupling RouterServiceProviderBinding from service provider.</div>
<div style>I've just removed foreign key to ServiceProviders table.</div><div style>I think this needs to be fixed in the patch which introduces the code which uses it (like the one published by Salvatore)</div><div style>
<br></div><div style>Thanks,</div><div style>Eugene.</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 2:33 PM, Akihiro MOTOKI <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.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"><div><div>Hi,</div><div><br></div><div>Sorry for late cut-in,</div><div><br></div><div>I agree that dynamic configuration through the API is not easy to implement.</div>
<div>At now, conf-based approach without database (option-1) looks the best way unless we</div>
<div>don't have needs for dynamic configuration thru the API.</div><div class="im"><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><div class="im"><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><br></div></div><div>I think ID is not necessarily required.</div><div>In DB approach, we can specify multiple fields as a primary key.</div>
<div>In in-memory approach, we can use a json-serialized string as a key</div><div>like json.dumps({'type': 'xxx', 'name': 'yyy'}).</div><div><br></div><div>In typical use cases,</div><div>
(1) neutron-server retrieves a provider from assocation table</div><div> (which is usually implemented on database)</div><div>(2) neutron-server determines a driver from a provider.</div><div>In this case, dict-based approach does enough I believe.</div>
<div>Is there any other typical access pattern?</div><div class="im"><div><br></div><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><br></div></div><div>As long as we don't have more keys than type and name to identify providers,</div><div>(type, name) combination looks simple enough.</div><div><br></div><div>"service provider" is similar to "flavor" in nova at some point.</div>
<div>"flavor" represents a combination of many fields.</div><div>If there is a possible case where a provider definition have more unique</div><div>keys, ID approach makes sense much.</div><div class="im"><div>
<br></div><div>> 4) From CLI perspective it's more convenient if resource has ID, it's a common way of specifying resource.</div>
<div><br></div></div><div>API perspective for an association from a resource to a provider,</div><div>a "type" is determined from a resource and what we need to specify is only "name".</div><div>As long as we can identify a provider by (type, name),</div>
<div>there is no difference between using "ID" and using "name".</div><div><br></div><div>Regarding a possible demerit without ID, it is difficult to specify a</div><div>specific provider to show its detail.</div>
<div>At now a provider has only a couple of visible field (type, name, default)</div><div>through API, so list-service-providers does enough and show-service-provider</div><div>does not provide more. (It just provides API consistency with other resources.)</div>
<div class="im">
<div><br></div><div>> 5) From user perspective it's more convenient to specify the name of service provider.</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>> </div><div><br></div></div><div>Thanks,</div><div>Akihiro</div></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">2013/7/10 Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, having so much pressure on db implementation, I think I'm just going to post in-memory implementation and we'll decide if it will fit our needs.<div>
<br></div><div>Thanks,</div><div>Eugene.</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 5:56 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 Mark<br>
<br>
<br>
2013/7/9 Mark McClain <<a href="mailto:mark.mcclain@dreamhost.com" target="_blank">mark.mcclain@dreamhost.com</a>>:<br>
<div>><br>
> On Jul 9, 2013, at 5:37 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>> wrote:<br>
>><br>
>> We have two suboption for db api based solution<br>
>><br>
>> Option4. REST API + DB with Preload with Conf<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>
>> so IMO, we can drop option3.<br>
>><br>
>> I believe option4 is easy to implement.<br>
>><br>
><br>
> I'm not onboard with option 4 either. At the last summit, we talked about making Neutron easier to deploy. Using a database to sync configuration state adds complexity. Having some values in a configuration and others in the database (even cached) is a recipe for a major headache. For the deployments running multiple instances of Neutron, they should be using Chef, Chef, Salt, etc for managing their configs anyway.<br>
><br>
> Using only configuration files (option 1) remains my preference.<br>
<br>
</div>"only configuration files (option 1)" is also acceptable for me.<br>
However, the headache continues even if we choose option1, because<br>
relation with service type<br>
and service resources are in the DB.<br>
<br>
Note that we still need to provide way to add or remove service types.<br>
<br>
Option1-1)<br>
Allow to create new relation if it appears in the conf.<br>
Remove the relation if it is disappears from conf.<br>
<br>
IMO, This will fall on same problem of current implementation<br>
<a href="https://docs.google.com/a/ntti3.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136</a><br>
<br>
Option1-2) Provide admin rest api for enable/disable service types<br>
Allow to create new relation if it is enabled by API<br>
Remove the relation if it disabled by API<br>
<br>
This is my preference. And IMO, this is same as option4.<br>
<br>
Best<br>
<span><font color="#888888">Nachi<br>
</font></span><div><div><br>
<br>
<br>
<br>
> mark<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>
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" 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></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>Akihiro MOTOKI <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>>
</font></span></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>