Thanks Engene,
I have looked at your new patch. It looks nice.
The router-provider association can be merged into service-provider
association,
but it can be done in another patch and I can do it.
I am also working to support multiple router implementations in NEC plugin
using this framework.
It is similar to Salvatore's distribution router patch.
Thanks,
Akihiro
2013/7/10 Salvatore Orlando <sorla...@nicira.com>
> Thanks Eugene,
>
> I am already looking at your new patch.
> Thankfully it seems that keeping providers in configuration files was not
> as hard as anticipated in previous rounds of reviews.
>
> I don't think what you did is a hack; I will fix rework the
> router-provider association extension in the distributed router patch or
> another patch.
> From my point of view, I think you can even remove altogether that code
> from your patch - if you don't feel happy about it.
> I will take care of restoring that extension afterwards; after all, it is
> outside of the scope of your blueprint.
>
> Salvatore
>
>
> On 10 July 2013 15:49, Eugene Nikanorov <enikano...@mirantis.com> wrote:
>
>> 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
>>
>>
>
> _______________________________________________
> 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
