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.
Thanks, Eugene. On Wed, Jul 10, 2013 at 5:56 AM, Nachi Ueno <na...@ntti3.com> wrote: > Hi Mark > > > 2013/7/9 Mark McClain <mark.mccl...@dreamhost.com>: > > > > On Jul 9, 2013, at 5:37 PM, Nachi Ueno <na...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
