<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 style>Thanks,</div><div style>Eugene.</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">mark.mcclain@dreamhost.com</a>>:<br>
<div class="im">><br>
> On Jul 9, 2013, at 5:37 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">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 class="HOEnZb"><font color="#888888">Nachi<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
> mark<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>