Open Stack

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 <nachi at ntti3.com> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/9649c61b/attachment.html>