[openstack-dev] [Neutron] Service Type Framework implementation
enikanorov at mirantis.com
Wed Jul 10 09:18:19 UTC 2013
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.
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
> >> 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.
> 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
> 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.
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev