Folks,
I have put initial in-memory implementation of service providers on review.
On of the 'hacks' I had to do is decoupling RouterServiceProviderBinding
from service provider.
I've just removed foreign key to ServiceProviders table.
I think this needs to be fixed in the patch which introduces the code which
uses it (like the one published by Salvatore)
Thanks,
Eugene.
On Wed, Jul 10, 2013 at 2:33 PM, Akihiro MOTOKI <amot...@gmail.com> wrote:
> Hi,
>
> Sorry for late cut-in,
>
> I agree that dynamic configuration through the API is not easy to
> implement.
> At now, conf-based approach without database (option-1) looks the best way
> unless we
> don't have needs for dynamic configuration thru the API.
>
> > 1) From logic perspective service provider could be referenced by
> (service_type, name) as it's unique primary key.
> > 2) From data normalization perspective it's better (and more convenient)
> to have an unique ID in resource provider model.
> > Obviously having ID works for DB implementation and doesn't work for
> in-memory implementation.
> > In other words, we can't use ID if we go with in-memory implementation.
>
> I think ID is not necessarily required.
> In DB approach, we can specify multiple fields as a primary key.
> In in-memory approach, we can use a json-serialized string as a key
> like json.dumps({'type': 'xxx', 'name': 'yyy'}).
>
> In typical use cases,
> (1) neutron-server retrieves a provider from assocation table
> (which is usually implemented on database)
> (2) neutron-server determines a driver from a provider.
> In this case, dict-based approach does enough I believe.
> Is there any other typical access pattern?
>
> > 3) From data modelling perspective it's better to have ID in service
> provider model as referencing models will be simpler and easier to maintain.
>
> As long as we don't have more keys than type and name to identify
> providers,
> (type, name) combination looks simple enough.
>
> "service provider" is similar to "flavor" in nova at some point.
> "flavor" represents a combination of many fields.
> If there is a possible case where a provider definition have more unique
> keys, ID approach makes sense much.
>
> > 4) From CLI perspective it's more convenient if resource has ID, it's a
> common way of specifying resource.
>
> API perspective for an association from a resource to a provider,
> a "type" is determined from a resource and what we need to specify is only
> "name".
> As long as we can identify a provider by (type, name),
> there is no difference between using "ID" and using "name".
>
> Regarding a possible demerit without ID, it is difficult to specify a
> specific provider to show its detail.
> At now a provider has only a couple of visible field (type, name, default)
> through API, so list-service-providers does enough and
> show-service-provider
> does not provide more. (It just provides API consistency with other
> resources.)
>
> > 5) From user perspective it's more convenient to specify the name of
> service provider.
> > But that is usually solved either by Horizon or by cli, like it's done
> for networks/subnets where name of the object is specified.
> >
>
> Thanks,
> Akihiro
>
>
>
> 2013/7/10 Eugene Nikanorov <enikano...@mirantis.com>
>
>> 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
>>
>>
>
>
> --
> Akihiro MOTOKI <amot...@gmail.com>
>
> _______________________________________________
> 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
