Open Stack

Hi Mark


2013/7/9 Mark McClain <mark.mcclain at dreamhost.com>:
>
> On Jul 9, 2013, at 5:37 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>>
>> We have two suboption for db api based solution
>>
>> Option4. REST API + DB with Preload with Conf
>> https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00
>>
>> so IMO, we can drop  option3.
>>
>> I believe option4 is easy to implement.
>>
>
> 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.
>
> Using only configuration files (option 1) remains my preference.

"only configuration files (option 1)"  is also acceptable for me.
However, the headache continues even if we choose option1, because
relation with service type
and service resources are in the DB.

Note that we still need to provide way to add or remove service types.

Option1-1)
   Allow to create new relation if it appears in the conf.
   Remove the relation if it is disappears from conf.

   IMO, This will fall on same problem of current implementation
   https://docs.google.com/a/ntti3.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136

Option1-2) Provide admin rest api for enable/disable service types
    Allow to create new relation if it is enabled by API
     Remove the relation if it disabled by API

    This is my preference. And IMO, this is same as option4.

Best
Nachi




> mark
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev